Programming is boring
dividebyze.ro
dividebyze.ro
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.)
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.
Sorry for rambling. Just got home and it's 1am here :)
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 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)
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.
...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.
- 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.
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?
(But seriously, I do both of these to test/verify the distributed systems on which I work -- both are great ideas)
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.
I would be bored to death if my days only involved programming.
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.
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.
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...
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.
I try to make the compiler do the boring stuff.
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.
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.