Programming is boring(dividebyze.ro)
dividebyze.ro
Programming is boring
http://dividebyze.ro/2016/11/04/programming-is-boring.html
74 comments
I'm 34 years old and have been programming since I was 14. I loved it from day one. I still love it. Even after tens of thousands of hours, two CS degrees, and hundreds of projects, I still am still amazed that I get to get up every day, go to my office in the basement, and can literally type into existence complex systems. I love it. I love the problem solving and making stuff work. I get frustrated with people from time to time, but on balance I want to continue to be a programmer as long as I live.
I'm with you 100%, just 2 years older. It's fun, and it's a huge privilege, especially when you take the historical view of human work. I don't want to move up a management ladder. I want to program until I retire.
I love the part where I type complex systems into existence. The part where I have to figure out the complex systems other people have typed into existence, not so much.
I'm the exact same way I'm still very new in my career - I often hear co-workers say "The last thing I want to see/do when I go home is a computer"
I'm the exact opposite of that. I work full time as a programmer - go home - do more things on the computer or work on tech related things. Maybe since I'm younger I feel this way, but I ~really~ don't think like my mind will change.
I'm the exact opposite of that. I work full time as a programmer - go home - do more things on the computer or work on tech related things. Maybe since I'm younger I feel this way, but I ~really~ don't think like my mind will change.
I'm the same way. I wouldn't want to go home and do what I do at work, but I love programming things that I choose to program.
"I wouldn't want to go home and do what I do at work, but I love programming things that I choose to program."
This statement here is what has kept me a good distance away from developer positions. I love to come up with programs, study them generally, and even /potentially/ develop a new branch of mathematics with which to frame my ideas BUT I can't bring myself to write code for cash (unless the program is something I came up with personally and just happens to be worth something to someone else.. but even then I dislike the added stress of selling a hobby project).
tl;dr: I like to program BUT my consideration of having fun doesn't involve production-ready code. (In fact, I'm not sure what would make code production-ready [cleansing user inputs(?)], so perhaps it already is.)
This statement here is what has kept me a good distance away from developer positions. I love to come up with programs, study them generally, and even /potentially/ develop a new branch of mathematics with which to frame my ideas BUT I can't bring myself to write code for cash (unless the program is something I came up with personally and just happens to be worth something to someone else.. but even then I dislike the added stress of selling a hobby project).
tl;dr: I like to program BUT my consideration of having fun doesn't involve production-ready code. (In fact, I'm not sure what would make code production-ready [cleansing user inputs(?)], so perhaps it already is.)
What is boring is having to spend eight hours a day among people who think that programming is boring.
Hackernews fetishes articles from managerial programmer types who have come down from the mountain of business mediocrity to tell all people with creativity and passion that it's getting in their way.
From my experience, managerial types in general seem to not think much at all about whether programming is boring or not. They usually concern themselves with other things. But those who do, and, worse yet, find programming exciting - those are the ones that tend to wreak havok and end up inflicting the biggest damage.
What sort of damage is that ? I'm of just the opposite opinion. There's people who like to talk about programs, and there's people who like to program. Those who like to talk about it ... well this somehow seems to be appreciated by everyone but they never accomplish anything.
The thing is, I've seen people who love programming learn how to get the talking part down. I've never seen one who seem to enjoy the talking more fix the inability of meetings to achieve anything. Everybody is always convinced meetings fix things, but they never do.
The people who love meetings really seem to hate people who just want to actually do things though. I even think I know why. Actually doing something real, like creating a working program, kills what the organization, the team is doing, for the very simple reason that it's now done. And clients respond to that: either take what is actually there and working or talk about it some more ... well they'll take the working thing every time, after all, that's why they're clients. So for the meeting maniacs this sucks : no more talking about it. No more talking about the need for more people to achieve things. No more getting promoted or getting more reports. No more having meetings about the need for more meetings. No more publishing internal memos about the need for a new standard for publishing meeting standards within the organization (no joke: there is an actual file shared with everyone in my company that's exactly that).
The thing is, it's the life cycle of organizations. When an organization comes into being, there are few meetings, and only when truly necessary. People just go off and do things and little regard is placed into communication ... because doing anything other than actually programming/working would kill the business. Then they get bigger, and bigger and bigger. Not because, but despite the meetings, and at this point there come ever more and more and yet again more meetings. And then meeting paralysis finally kills the business. Nobody is able to achieve anything, why ? Because the meeting folks have convinced management to block people doing things without agreement from, by this point, thousands of other employees. Everything the business does becomes a disappointment, first just internally, then it becomes visible to clients, then someone successfully actually does what this company needs to do, and clients leave in droves. And what does the meeting-infested company do ?
They have endless meetings on what could possibly be wrong. Ironically, this is used as an argument to prevent engineers from doing anything because they'll just make it worse !
I once heard a joke that being a lawyer is a sweet gig: the more lawyers there are, and the more they work, the more lawyers are needed to deal with the problems created. Meetings truly are like that.
The thing is, I've seen people who love programming learn how to get the talking part down. I've never seen one who seem to enjoy the talking more fix the inability of meetings to achieve anything. Everybody is always convinced meetings fix things, but they never do.
The people who love meetings really seem to hate people who just want to actually do things though. I even think I know why. Actually doing something real, like creating a working program, kills what the organization, the team is doing, for the very simple reason that it's now done. And clients respond to that: either take what is actually there and working or talk about it some more ... well they'll take the working thing every time, after all, that's why they're clients. So for the meeting maniacs this sucks : no more talking about it. No more talking about the need for more people to achieve things. No more getting promoted or getting more reports. No more having meetings about the need for more meetings. No more publishing internal memos about the need for a new standard for publishing meeting standards within the organization (no joke: there is an actual file shared with everyone in my company that's exactly that).
The thing is, it's the life cycle of organizations. When an organization comes into being, there are few meetings, and only when truly necessary. People just go off and do things and little regard is placed into communication ... because doing anything other than actually programming/working would kill the business. Then they get bigger, and bigger and bigger. Not because, but despite the meetings, and at this point there come ever more and more and yet again more meetings. And then meeting paralysis finally kills the business. Nobody is able to achieve anything, why ? Because the meeting folks have convinced management to block people doing things without agreement from, by this point, thousands of other employees. Everything the business does becomes a disappointment, first just internally, then it becomes visible to clients, then someone successfully actually does what this company needs to do, and clients leave in droves. And what does the meeting-infested company do ?
They have endless meetings on what could possibly be wrong. Ironically, this is used as an argument to prevent engineers from doing anything because they'll just make it worse !
I once heard a joke that being a lawyer is a sweet gig: the more lawyers there are, and the more they work, the more lawyers are needed to deal with the problems created. Meetings truly are like that.
Looks like you did an excellent job answering your own, now almost rhetorical, question.
This is something I've thought about quite a few times. It's almost counter-intuitive. The community that we surround ourselves in keeps telling us how exciting XYZ technology is. But at the end of the day it comes down to reading documentation/man pages, and trying to implement something that you're trying to get up and running. I ascribe this feeling of boredom that I get partially to my perfectionism. But a lot of the times, it's just...why? Frankly, I'd rather just enjoy life. Programming is great. Latest technology in language XYZ or framework ABC is fantastic. But there's more to life than that.
Sorry for rambling. Just got home and it's 1am here :)
Sorry for rambling. Just got home and it's 1am here :)
Programming is beautiful!
I'm writing an authorization expression parser that generates a Validation applicative functor (whose errors form a semi-group, so cool!). The users will only notice that the error messages when they fail authorization will be descriptive of what they're missing. The developers love it because they get a rich, descriptive language. And it makes me happy because it's actually not a lot of code.
If I had written it the boring way there would probably be more code, be less useful, and I would've tried to find some way to punt the work onto someone else.
Beautiful code is not just a way to check of your *-ility's. It's also inspirational. And being inspired leads to creative solutions which amplify the value you can generate. Sometimes the boring solutions lead to byzantine, institutional code whose intent, purpose, and function remains a mystery.
For me clarity and utility stem not from documentation and mountains of tests. It comes from being succinct, clear, and precise. At least the author and I agree on one point: simplicity is key.
I'm writing an authorization expression parser that generates a Validation applicative functor (whose errors form a semi-group, so cool!). The users will only notice that the error messages when they fail authorization will be descriptive of what they're missing. The developers love it because they get a rich, descriptive language. And it makes me happy because it's actually not a lot of code.
If I had written it the boring way there would probably be more code, be less useful, and I would've tried to find some way to punt the work onto someone else.
Beautiful code is not just a way to check of your *-ility's. It's also inspirational. And being inspired leads to creative solutions which amplify the value you can generate. Sometimes the boring solutions lead to byzantine, institutional code whose intent, purpose, and function remains a mystery.
For me clarity and utility stem not from documentation and mountains of tests. It comes from being succinct, clear, and precise. At least the author and I agree on one point: simplicity is key.
> I'm writing an authorization expression parser that generates a Validation applicative functor (whose errors form a semi-group, so cool!).
It's either the successful result or a list of errors. That's what you're describing here. Boom -- boringified.
It's either the successful result or a list of errors. That's what you're describing here. Boom -- boringified.
Well, if you do that with the right interface, a "successful result or a list of errors" is a "Validation applicative functor (whose errors form a semi-group)".
hmm yes but what if we construe boringification as decategorification of the n-category of interesting algebraic constructions?
> If I had written it the boring way there would probably be more code, be less useful
It's the bugs. If you write it the boring way, it will be complex enough to be full of bugs. And it will need to change all the time. And next thing you see is that you are now working full time on improving error messages and can't afford to do anything interesting anymore.
Still, that excitement comes from making things less complex. KISS always apply.
It's the bugs. If you write it the boring way, it will be complex enough to be full of bugs. And it will need to change all the time. And next thing you see is that you are now working full time on improving error messages and can't afford to do anything interesting anymore.
Still, that excitement comes from making things less complex. KISS always apply.
Sorry I don't understand what you built, but it seems interesting, can you please explain it in plain English.
Sure!
The problem I need to solve is to add an authorization system to our stack.
Because we need to support a good number of authorization scenarios the system needs to be flexible.
So I wrote an expression parser that takes an "authorization expression" in my input language and outputs a function. That function takes the authorization context and either returns a Success value or a list of Failure.
The pattern I'm using to generate that function is called a "Validation." It's a kind of applicative functor which is essentially a list of functions we map over. The result is the success value or a semi-group of the failed functions. All my expression parser has to do is generate the "list of functions" to feed into the Validation.
This is really cool because now I can write very expressive authorization clauses and it always generates a nice function that either passes or gives the user a nice list of the exact conditions that failed. It's a surprisingly small amount of code for such a handy tool... Which means it's simple in the sense that it's precise and succinct.
Savvy?
I took some liberties with the definition of what an applicative functor is. If you're interested there are a great number of resources to learn about them and I encourage everyone to read up and try to understand the true definition themselves.
The problem I need to solve is to add an authorization system to our stack.
Because we need to support a good number of authorization scenarios the system needs to be flexible.
So I wrote an expression parser that takes an "authorization expression" in my input language and outputs a function. That function takes the authorization context and either returns a Success value or a list of Failure.
The pattern I'm using to generate that function is called a "Validation." It's a kind of applicative functor which is essentially a list of functions we map over. The result is the success value or a semi-group of the failed functions. All my expression parser has to do is generate the "list of functions" to feed into the Validation.
This is really cool because now I can write very expressive authorization clauses and it always generates a nice function that either passes or gives the user a nice list of the exact conditions that failed. It's a surprisingly small amount of code for such a handy tool... Which means it's simple in the sense that it's precise and succinct.
Savvy?
I took some liberties with the definition of what an applicative functor is. If you're interested there are a great number of resources to learn about them and I encourage everyone to read up and try to understand the true definition themselves.
sooo :: Foldable b => String -> (a -> Either a b)
This times a thousand.
I love programming but I want it to be boring. Boring means no stress, attainable deadlines, repeat ability, the ability to walk away, and the ability to tell these 10-hours-a-day hacks to fuck off. Boring means 5-nines reliability without a devops team because the design was simple, elegant, and most importantly worked. Boring means you're able to get it right the first time. Boring means being able to have a life, with other passions or hobbies completely unrelated to programming or code or geeks, which frankly everybody needs because we nerds are an unbearable bunch.
I want to slap all these Show-HN innovation fetishists that reinvent the same thing over and over again. They make life worse for everyone.
I love programming but I want it to be boring. Boring means no stress, attainable deadlines, repeat ability, the ability to walk away, and the ability to tell these 10-hours-a-day hacks to fuck off. Boring means 5-nines reliability without a devops team because the design was simple, elegant, and most importantly worked. Boring means you're able to get it right the first time. Boring means being able to have a life, with other passions or hobbies completely unrelated to programming or code or geeks, which frankly everybody needs because we nerds are an unbearable bunch.
I want to slap all these Show-HN innovation fetishists that reinvent the same thing over and over again. They make life worse for everyone.
You just described the fixed mindset to a T.
https://www.brainpickings.org/2014/01/29/carol-dweck-mindset...
How?
I've seen this chart and it has very little to do with what is described above. My point isn't that people should reject challenges, or to push back unnecessarily when confronted with pressure, or resist deadlines. The point is that you optimize your environment, methodology, tool usage, workflow, designs for simplicity, and that when you've done so it grants a level of control and predictability over one's work that it would appear you guys think is unattainable.
The above mindset embraces challenges by controlling for their parameters, and when confronted with a challenge too large you break it up until the pieces are something that one can assert control over. If that's still too much then you start shaving off requirements, and if that's still too much then yes, you might have to dive in and power through it. But that's where the boring mentality saves you: "diving in" and "powering through it" become more like a light swim than a sprint or marathon. Plus, when the code is simple and predictable its very easy to make estimates and then you can give yourself a larger deadline than you need.
Obstacles are confronted and plowed through -- but again this is not as difficult because the system is simple enough that most of it can be held in one person's head. When that fails, though, a little bit of creativity can get one out of a bind.
Effort... well you got me there. Less work is always better. Smart work, not hard work. If you are working hard, step back and think for a minute, because you are doing it wrong and you should probably optimize. There are very few scenarios for which this rule doesn't apply.
I don't see how my assertions have anything to do with feedback and criticism, other than to say that there is not as much in the bugs department because the boring system generally works. How one handles feedback has little to do with the other components.
It should also be noted that my mentality DOES involve a lot of questioning management, but that is because management desperately needs questioning. When a cabal of socializers and non-technical soft-power types try to run a technology-centered business, they require a lot of course correction so that development can continue unhindered and not get distracted with silly little initiatives (or whatever the third-party enterprise sales hacks walked through the door with this week)
I've seen this chart and it has very little to do with what is described above. My point isn't that people should reject challenges, or to push back unnecessarily when confronted with pressure, or resist deadlines. The point is that you optimize your environment, methodology, tool usage, workflow, designs for simplicity, and that when you've done so it grants a level of control and predictability over one's work that it would appear you guys think is unattainable.
The above mindset embraces challenges by controlling for their parameters, and when confronted with a challenge too large you break it up until the pieces are something that one can assert control over. If that's still too much then you start shaving off requirements, and if that's still too much then yes, you might have to dive in and power through it. But that's where the boring mentality saves you: "diving in" and "powering through it" become more like a light swim than a sprint or marathon. Plus, when the code is simple and predictable its very easy to make estimates and then you can give yourself a larger deadline than you need.
Obstacles are confronted and plowed through -- but again this is not as difficult because the system is simple enough that most of it can be held in one person's head. When that fails, though, a little bit of creativity can get one out of a bind.
Effort... well you got me there. Less work is always better. Smart work, not hard work. If you are working hard, step back and think for a minute, because you are doing it wrong and you should probably optimize. There are very few scenarios for which this rule doesn't apply.
I don't see how my assertions have anything to do with feedback and criticism, other than to say that there is not as much in the bugs department because the boring system generally works. How one handles feedback has little to do with the other components.
It should also be noted that my mentality DOES involve a lot of questioning management, but that is because management desperately needs questioning. When a cabal of socializers and non-technical soft-power types try to run a technology-centered business, they require a lot of course correction so that development can continue unhindered and not get distracted with silly little initiatives (or whatever the third-party enterprise sales hacks walked through the door with this week)
>I want to slap all these Show-HN innovation fetishists that reinvent the same thing over and over again. They make life worse for everyone.
>we nerds are an unbearable bunch.
1/ No one forces you to use what someone show case to the community
2/ Creation is encouraged and this is good. That certainly isn't mutually exclusive with you being cautious about the tools you chose to work with. If you think a pre-alpha physic simulation framework is good to use for your nuclear reactor, you're the one to blame.
3/ Your diatribe on boring-ness is completely off-topic which makes me wonder if you actually read the article or jumped in because the title seemed fitting.
>we nerds are an unbearable bunch.
1/ No one forces you to use what someone show case to the community
2/ Creation is encouraged and this is good. That certainly isn't mutually exclusive with you being cautious about the tools you chose to work with. If you think a pre-alpha physic simulation framework is good to use for your nuclear reactor, you're the one to blame.
3/ Your diatribe on boring-ness is completely off-topic which makes me wonder if you actually read the article or jumped in because the title seemed fitting.
Did YOU read the article? Dude extolls the virtues of a stable programming environment and I am simply providing examples from my own experiences boring-ifying previously exciting code.
And you're right, noone forces anyone to use anything on Show HN. But do you not see anything wrong with a lot of these projects, where a fancy CSS-and-nodeJS-atrocity slides and glimmers around the fact that it's hiding alpha-quality code? (Rehashing production-level ideas no less) Sure we on HN know it's just show-and-tell, but what about others? Just yesterday there was a Show HN that was all web site and no product -- in fact I think it used more screen space to document what their project lacked as opposed to what it had. If what was posted a zip with a readme.txt that'd be one thing, but instead we have ideas masquerading as products.
Just as bad are all these security wonks that need to give their vulnerabilities nice, marketable nicknames. It was effective the first time, but now it's just obnoxious -- file a CVE and let the community decide!
And you're right, noone forces anyone to use anything on Show HN. But do you not see anything wrong with a lot of these projects, where a fancy CSS-and-nodeJS-atrocity slides and glimmers around the fact that it's hiding alpha-quality code? (Rehashing production-level ideas no less) Sure we on HN know it's just show-and-tell, but what about others? Just yesterday there was a Show HN that was all web site and no product -- in fact I think it used more screen space to document what their project lacked as opposed to what it had. If what was posted a zip with a readme.txt that'd be one thing, but instead we have ideas masquerading as products.
Just as bad are all these security wonks that need to give their vulnerabilities nice, marketable nicknames. It was effective the first time, but now it's just obnoxious -- file a CVE and let the community decide!
I agree with your notion of the importance of balance in a developer's life. I think work-life balance is important, no matter what your profession is.
However, behind every successful, well-crafted software project are still business needs and decisions. And a lot of the time, these businesses' success can rely on being faster than competitors. Obviously it is ideal to have attainable deadlines, but it is not always possible. Inevitably, there will be times of stressful, tight deadlines. With your firm attitude, I'd be curious to see how you might handle those situations.
However, behind every successful, well-crafted software project are still business needs and decisions. And a lot of the time, these businesses' success can rely on being faster than competitors. Obviously it is ideal to have attainable deadlines, but it is not always possible. Inevitably, there will be times of stressful, tight deadlines. With your firm attitude, I'd be curious to see how you might handle those situations.
I'm able to roll with business deadlines as needed. Programming can actually be a very quick, predictable endeavor once necessary infrastructure and management expectations are in place. As with all jobs, one needs to manage their manager (and management) to make sure expectations are in line with requirements and availability. Built-up influence, gained from prior successes, helps a lot.
Also: be in an industry where you're the last man standing and barriers to entry are high. Really helps dealing with competition-influenced deadlines :)
Also: be in an industry where you're the last man standing and barriers to entry are high. Really helps dealing with competition-influenced deadlines :)
Programming is boring after five years of CRUD/"business"/"enterprise" apps. Unfortunately they make up the majority of the jobs out there but making the effort to get a more interesting job is worth it.
I love building CRUD apps! I guess I'm fascinated by learning different business models and mapping them to code.
I'd love to hear more about your workflow! It sounds like you've been able to take a thing people consider tedious, and find joy in it.
It's nothing special - I'm just genuinely interested in learning about other people's problems. Every organisation has some pain points that can be solved with a CRUD app, and I love discovering them.
I know my tools very well, keep up to date with trends, and I'm constantly grateful at how lucky I've been. I'm a very mediocre developer, but I'm fantastically well paid for a job that really isn't very difficult.
FWIW - I use Symfony (especially the form bundle), Behat, and nginx. At some point, I want to start building Angular front ends as well. I try to be Agile by delivering early and often.
I know my tools very well, keep up to date with trends, and I'm constantly grateful at how lucky I've been. I'm a very mediocre developer, but I'm fantastically well paid for a job that really isn't very difficult.
FWIW - I use Symfony (especially the form bundle), Behat, and nginx. At some point, I want to start building Angular front ends as well. I try to be Agile by delivering early and often.
Everything is boring in a repetitive job. Ask the baker if putting the same kind of bread in the oven every morning is any fun.
That's why you do personal project.
For the baker it could be baking a complicated recipe.
For the programmer it's learning something new and solving new problems... well, for the programmer it's also baking a complicated recipe.
That's why you do personal project.
For the baker it could be baking a complicated recipe.
For the programmer it's learning something new and solving new problems... well, for the programmer it's also baking a complicated recipe.
"and making sure your solution is easy to maintain and nurture in the future"
...this is why programming is boring
there's nothing actually more exciting then building out a whole idea and being like "didn't exist, now it exists and i built it."
making it maintainable is a thing, but it's separate from that initial excitement. i never go "man i can't wait to make this thing maintainable and write a bunch of tests and shit omg"
i approach programming as more of a way to make cool art. so idk i might be different from most programmers.
he's got some good points though.
...this is why programming is boring
there's nothing actually more exciting then building out a whole idea and being like "didn't exist, now it exists and i built it."
making it maintainable is a thing, but it's separate from that initial excitement. i never go "man i can't wait to make this thing maintainable and write a bunch of tests and shit omg"
i approach programming as more of a way to make cool art. so idk i might be different from most programmers.
he's got some good points though.
Writing something new and cool gets me out of bed in the morning. Writing tests for my code lets me sleep peacefully at night. Can't have one without the other.
I dunno, I can often code faster if I'm writing unit tests along with my feature, I spend less time being confused about whether things are doing what I expect
People who say programming is boring belong to one or more of the following groups
- people who haven't explored the concept enough, which may be a symptom of a larger issue possibly and most likely the one below
- people who are just in for the money and are trying to convince themselves otherwise
- people who don't know how to use atomic concepts to make more interesting concepts because they lack creativity and imagination (whatever these terms in comp sci domain)
- people who haven't explored the concept enough, which may be a symptom of a larger issue possibly and most likely the one below
- people who are just in for the money and are trying to convince themselves otherwise
- people who don't know how to use atomic concepts to make more interesting concepts because they lack creativity and imagination (whatever these terms in comp sci domain)
I'm learning an instrument over last few years. To be honest it's super boring to practice the same notes over and over again. Then again all the skills I learned I learned through boring repetitions.
So if someone tells me programming is boring I'll just nod. It takes too many repetitions to finally start to appreciate something.
So if someone tells me programming is boring I'll just nod. It takes too many repetitions to finally start to appreciate something.
How do you know that? Have you exhaustively categorized the full range of experience of programmers?
I would like to propose that we all investigate how we can be more scientific about our programming.
I imagine we can create artificial scenarios wherein we subject our code to rigged experiments. These experiments can serve to isolate parts of our codebases, pushing known values as inputs to the part and then inspecting the output for what we expect are correct values. We can posit theories about how our code should work, and then test those theories with experiments.
I envision a few benefits to these experiments:
1) isolating our modules to make experimenting easy may help to reduce the complexity of our programs.
2) overall 'correctness', whatever we define that to be, can continue to be verified over time as our programs change and grow as long as we update the expected values in our experiments at the same time or create additional experiments as needed.
3) the experiments themselves will serve as a kind of documentation of the codebase because they will show the code in action in fine detail.
What does everyone think of my idea? I know it sounds like an odd proposition, but science seems to work good in other disciplines. Maybe we can try it in ours?
I imagine we can create artificial scenarios wherein we subject our code to rigged experiments. These experiments can serve to isolate parts of our codebases, pushing known values as inputs to the part and then inspecting the output for what we expect are correct values. We can posit theories about how our code should work, and then test those theories with experiments.
I envision a few benefits to these experiments:
1) isolating our modules to make experimenting easy may help to reduce the complexity of our programs.
2) overall 'correctness', whatever we define that to be, can continue to be verified over time as our programs change and grow as long as we update the expected values in our experiments at the same time or create additional experiments as needed.
3) the experiments themselves will serve as a kind of documentation of the codebase because they will show the code in action in fine detail.
What does everyone think of my idea? I know it sounds like an odd proposition, but science seems to work good in other disciplines. Maybe we can try it in ours?
You heard it here folks! HN just invented formal methods of verification and fizz testing! ;)
(But seriously, I do both of these to test/verify the distributed systems on which I work -- both are great ideas)
(But seriously, I do both of these to test/verify the distributed systems on which I work -- both are great ideas)
Programming might be boring. Engineering is not.
Truth but unlike other professions, throughout the rise of the internet, github, what-have-you, we, programmers have been able to counter the boringness and move to other opportunities in the industry.
For example, someone who wrote test hardware code in embedded C, can move towards full software iOS development which is at two ends of the tech industry. The opportunity produces excitement and the further attainment of knowledge.
On the other side of the spectrum, a pilot who flies a Boeing 777 will not be able to easily switch to flying an Airbus 330.
Simply said, programming is boring, if you make it so.
For example, someone who wrote test hardware code in embedded C, can move towards full software iOS development which is at two ends of the tech industry. The opportunity produces excitement and the further attainment of knowledge.
On the other side of the spectrum, a pilot who flies a Boeing 777 will not be able to easily switch to flying an Airbus 330.
Simply said, programming is boring, if you make it so.
> On the other side of the spectrum, a pilot who flies a Boeing 777 will not be able to easily switch to flying an Airbus 330.
This sounds super dubious, I feel like you fell down on this analogy. I mean, they probably have some different controls and systems, but you can probably just run co-pilot for a few flights to get acquainted and then be good to go (leaving out the fact that most commercial planes essentially fly themselves for most of the trip these days anyhow)
This sounds super dubious, I feel like you fell down on this analogy. I mean, they probably have some different controls and systems, but you can probably just run co-pilot for a few flights to get acquainted and then be good to go (leaving out the fact that most commercial planes essentially fly themselves for most of the trip these days anyhow)
Ah yes. To be honest, both examples I used are real life examples. My brother happens to be a 777 pilot. He tells me it's not really feasible for him to transfer to an Airbus. He can see himself flying another Boeing, but both would take years+ of training.
[deleted]
> a pilot who flies a Boeing 777 will not be able to easily switch to flying an Airbus 330.
Can you provide more detail on that? Pilots have to be "type rated" for the aircraft they fly, and some aircraft share type ratings because they are substantially similar. Flight Training International shows the same amount of time for A330 and B777 training, with the most intense complete training course lasting two weeks (plus "homework").
Can you provide more detail on that? Pilots have to be "type rated" for the aircraft they fly, and some aircraft share type ratings because they are substantially similar. Flight Training International shows the same amount of time for A330 and B777 training, with the most intense complete training course lasting two weeks (plus "homework").
Ah yes. To be honest, both examples I used are real life examples. My brother happens to be a 777 pilot. He tells me it's not really feasible for him to transfer to an Airbus. He can see himself flying another Boeing, but both would take years+ of training.
I guess you can say I exaggerated a bit. It might not be impossible. It's just you wouldn't really do it or as he tells me.
I guess you can say I exaggerated a bit. It might not be impossible. It's just you wouldn't really do it or as he tells me.
The part I like the most is refactoring -- once the problem is solved, the requirements are all completely defined -- going back and making it as clean and organized as possible.
All of the stuff that comes before, after and in-between the programming part is what's exciting imo. The idea phase is exciting. The planning phase is exciting. The thrill of seeing users use what you have programmed is exciting. Being able to iterate upon user feedback is exciting. Watching something that you programmed grow into a useful and productive app is exiting.
I would be bored to death if my days only involved programming.
I would be bored to death if my days only involved programming.
"You don’t create “possible problems” of the future, you don’t pigeonhole the solution in to some tool you fancy learning and working with; that’s called over-engineering -- ..and keep it simple. That’s what being professional means."
The author goes as far as making an analogy between doctor:chest-pain as programmer:program-features to argue the dangers of acting unprofessional but I'd argue that always acting professional can lead to insufficient solutions in the long run.
Creating "possible problems of the future" is often what keeps me on track in the present. Often times I will finish developing a feature prior to fully writing its foundation so as to see how the feature might influence the foundation. It seems a bit ironic but I'd claim over-engineering is what keeps a code-base flexible to change.
But perhaps the type of development I enjoy is unprofessional. It would make sense in explaining why I haven't made a dime on my code.
The author goes as far as making an analogy between doctor:chest-pain as programmer:program-features to argue the dangers of acting unprofessional but I'd argue that always acting professional can lead to insufficient solutions in the long run.
Creating "possible problems of the future" is often what keeps me on track in the present. Often times I will finish developing a feature prior to fully writing its foundation so as to see how the feature might influence the foundation. It seems a bit ironic but I'd claim over-engineering is what keeps a code-base flexible to change.
But perhaps the type of development I enjoy is unprofessional. It would make sense in explaining why I haven't made a dime on my code.
This article is wrong. It assumes that priorities are the same for all programming.
When programming you should be programming to a set of priorities i.e.:
software performance/speed
maintainability
security
reliability
conformance to organisational statndards
conformance to testing requirements
time to market
compatibility
research/problem solving
prototyping
probably more...
The priorities of your project dictate your approach.
This guy says one size fits all.
When programming you should be programming to a set of priorities i.e.:
software performance/speed
maintainability
security
reliability
conformance to organisational statndards
conformance to testing requirements
time to market
compatibility
research/problem solving
prototyping
probably more...
The priorities of your project dictate your approach.
This guy says one size fits all.
Great! Since programming is so boring all that's left is to start understanding system administration concepts as well and making things easier for your ops team. Right? Right????????
It has a flamebait title, jumps straight into false dichotomies and straw man arguments, and is talking about something that's obviously personal opinion. Looks like a troll, IMO.
When I got married, as part of our pre-marital counseling, we had to take a personality test. One question I got rated as a "2" (on a scale of 1-5), but I couldn't figure out what the question meant.
Turns out that in our world, it's product lifecycle. 1 is initial conception, 2 is prototype, 3 is rollout, 4 is major enhancement, and 5 is maintenance. My personality is that I find maintenance boring.
But that isn't necessarily true of all programmers...
Turns out that in our world, it's product lifecycle. 1 is initial conception, 2 is prototype, 3 is rollout, 4 is major enhancement, and 5 is maintenance. My personality is that I find maintenance boring.
But that isn't necessarily true of all programmers...
You can always give yourself challenges. See that famous kragen bootstrapping marathon: https://www.reddit.com/r/programming/comments/9x15g/programm...
Nope, in the way I encounter people it is: "Programming boils down to: understanding the problem, solving the problem, and making sure you are getting paid." which is quite far from "making sure your solution is easy to maintain and nurture in the future." because the future usually is not there.
If programming is boring, then you haven't abstracted enough things away or haven't automated enough things. Things become boring if you are doing the same thing over and over and if you are repeating yourself, then you are doing it wrong. Most of the time.
I have been programming digital computers for four decades and I still find them magical. A machine does things at your command while being composed of simple understandable parts -- programming is magic that works! How can that possibly be boring?
Since I was a child I thought that programming could be the amazing tool to create something that should be a breakthrough and would make me rich. I am still struggling to find that magical key, so I am not bored at all!
Writing something that is neat and and understandable is not boring.
It can be challenging and frustrating to get to that point, but it is pleasing once it is done.
Of course, that moment doesn't last for long at all before ascending the next hill.
It can be challenging and frustrating to get to that point, but it is pleasing once it is done.
Of course, that moment doesn't last for long at all before ascending the next hill.
omg I work with a dude now who is brilliant, prolific and super-efficient - he successfully rolls out twice the number of features the next best person does, but he leaves behind 0 comments ("code documents itself"), 0 unit tests ("unit tests are for rookies who are unsure about their code") and 0 documentation. How? How to get across the point that he's forcing all of us into the dead end when it comes to team scaling?
The boring stuff should be automated away, leaving only the fun parts.
I try to make the compiler do the boring stuff.
I try to make the compiler do the boring stuff.
Entertainment is subjective you fucking dweeb. Just say "I don't like programming, it's not for me" if you feel that way.
If you read TFA the author wasn't talking about programming being entertaining, he was talking about how the process should be consistent & unsurprising. A silly comparison, but not about what he finds exciting.
[deleted]
Programming is boring when you're solving mundane problems, when everything you need is already written in a nice library or package for you to put together like a 24 piece jigsaw puzzle.
Get yourself an arduino, maybe esp8266, now program it to do something exciting.
Another suggestion, an occasional after work punjabi sword fight might do the trick
Get yourself an arduino, maybe esp8266, now program it to do something exciting.
Another suggestion, an occasional after work punjabi sword fight might do the trick
Jigsaw puzzles are not boring, nor is mundane programming IMO. Challenging stuff is super fun of course but there is something satisfying and meditative about just doing a really meticulous job even if you are doing routine stuff. Just me?
Sorta not really, I get where you're going with it, but for me it's finishing the feature and getting it to work properly. This can involve wiring up some stuff for CRUD operations. But hey it works well and someone appreciates it, therefore I enjoy doing it.
Meticulous to me is when I have to pour over some very badly written code, carefully stepping over all the frayed knots and ducking under wires, trying to make that one fix without introducing another bug. Hoping to leave behind my little corner of the room in a slightly better state than I found it. It's a thankless job and always takes longer than expected. :(
Meticulous to me is when I have to pour over some very badly written code, carefully stepping over all the frayed knots and ducking under wires, trying to make that one fix without introducing another bug. Hoping to leave behind my little corner of the room in a slightly better state than I found it. It's a thankless job and always takes longer than expected. :(
I agree that jigsaw puzzles in general are not boring, but I also agree that 24-piece jigsaw puzzles are boring (at least, when they're not metaphorical)
And let's not forget that the analogy for the jigsaw puzzle falls apart when you consider that you may not know what pieces are available, pieces you think might fit end up not fitting, or that you may end up with massive holes that you have to paint pieces for yourself or you solve for a picture of the Amazon rain forest but now the client/customer wants Antarctica with half the time and budget, so you have to recycle and rearrange the pieces as much as possible. Or that once you've solved the puzzle, pieces start to melt because your room is too hot or change color because there is too much light.
Yes programing is boring indeed.
Yes programing is boring indeed.
Most of the comments are completely missing the point of the article. I thought it was pretty self explanatory. He's talking about the part where you write code.
I don't get pleasure from writing code. It is actually kinda boring...you've (mostly) already figured out what you're going to do and you're just typing. Most of the time you're fighting against the limitations of whatever programming environment/language/framework you may be using. It's more boring the more familiar I'm with the problem I'm working on.
I get excited when I finish and I see the actual impact of people actually using something I created. Or when I'm in the problem solving mode and I'm learning something new.
That's why I enjoy being a software engineer, not because I spend all day typing on a keyboard.
I don't get pleasure from writing code. It is actually kinda boring...you've (mostly) already figured out what you're going to do and you're just typing. Most of the time you're fighting against the limitations of whatever programming environment/language/framework you may be using. It's more boring the more familiar I'm with the problem I'm working on.
I get excited when I finish and I see the actual impact of people actually using something I created. Or when I'm in the problem solving mode and I'm learning something new.
That's why I enjoy being a software engineer, not because I spend all day typing on a keyboard.