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 :)
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
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. :(
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.
"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.
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
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.
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.
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.
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.
> 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)
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.
> 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").
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.
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.
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)
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.
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.
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????????
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'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 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.)
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.
This is unbelievably cringey and this person is in the wrong profession. The fact that they seriously pretend that good programming = boring is embarrassing, as is their caricature of people who enjoy the field as cowboys.
>Screw writing anything down or discussing your issues with you further! This is exciting! Oh if it goes wrong I’ll just quit because look at my CV, I’m doing triple heart bypasses like crazy!
This person needs a hug or something. Many doctors absolutely love their job. They love doing things that matter, and dealing with unique problems (and almost all problems are unique). Their anecdote is yet again a tired jealous screed trying to imagine themselves to be the good coder.
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...
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'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.
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)".
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.
> 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.
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.
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 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.
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.
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 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 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.
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!
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.
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 :)
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 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?
74 comments
[ 3.7 ms ] story [ 156 ms ] threadSorry for rambling. Just got home and it's 1am here :)
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
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. :(
Yes programing is boring indeed.
...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.
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.
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.
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.
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)
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").
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.
- 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)
So if someone tells me programming is boring I'll just nod. It takes too many repetitions to finally start to appreciate something.
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.
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.
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.)
>Screw writing anything down or discussing your issues with you further! This is exciting! Oh if it goes wrong I’ll just quit because look at my CV, I’m doing triple heart bypasses like crazy!
This person needs a hug or something. Many doctors absolutely love their job. They love doing things that matter, and dealing with unique problems (and almost all problems are unique). Their anecdote is yet again a tired jealous screed trying to imagine themselves to be the good coder.
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...
I would be bored to death if my days only involved programming.
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.
It's either the successful result or a list of errors. That's what you're describing here. Boom -- boringified.
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.
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.
I try to make the compiler do the boring stuff.
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.
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 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.
>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.
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!
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.
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 :)
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)