4 ms·

I suspect that when most organizations hire software developers, they're not really looking for great programmers. What they're really looking for is people wh

by elihu 8y ago

I suspect that when most organizations hire software developers, they're not really looking for great programmers. What they're really looking for is people who are capable of dealing with enormous complexity without getting confused. Those things might sound related, but I don't think they're the same thing. I expect that most software developers don't spend most of their time designing beautiful, elegant solutions to interesting problems; they spend their time blundering around in an over-complicated and poorly designed code-base using tools that barely work and trying not to trip over myriad corner cases or buried in technical debt. (Even in well-designed systems, you're often still dealing with mountains of technical debt inherited from the industry at large.) Maintaining bad code is in a lot of ways harder than creating good code. Or at least, a person good at one of those things might not be good at the other. I have a related theory that software development as a profession is starting to increasingly resemble being an air-traffic controller; as the actual programming parts get easier (languages, tools, and libraries get better, awful code-bases notwithstanding), the non-programming tasks tend to take up more and more time. So, you end up spending a lot more time talking to people and figuring out what to build.

fmax30 8y ago
What an interesting analogy to make with Air Traffic controllers. Although I still believe an Air Traffic Controller's job is more anxiety inducing and difficult. But the anaology does hold true. My Dad used to be an ATC and he always told me that he actually has fun doing it and loves his job. When I was little I was unable to comprehend how one can enjoy being in such a pressure situation. But now as I am older it makes more sense, as now whenever we are near a major release the pressure is still pretty high but I enjoy writing code and deliverying features too. Even if the code base is really annoying and the architecture of the platform makes me pull my hair out. It still is super satisfying to successfully do a release or when you fix that pesky bug. :)
munchbunny 8y ago
I think that's a good description. As I've become a more experienced software engineer, my job stopped being about making new features and switched to controlling chaos. Writing code that needs to be maintained for years is a very different problem than getting a lot of functionality out the door. Experience teaches you how to adjust for the right spot on the spectrum between "build for business value" and "build for maintainability."
- clarry 8y ago
  > As I've become a more experienced software engineer, my job stopped being about making new features and switched to controlling chaos. Isn't that funny. Get the inexperienced folk to churn out features so the experienced folk can enjoy the nightmare of perpetually repairing the monster.
  - munchbunny 8y ago
    This is why I like code reviews. It let's you make sure it's done with some thought for the future.
systematical 8y ago
This is sadly accurate. Though I do think it's harder to write good code then it is to maintain bad code.
trylist 8y ago
I'm starting to look at it from a different perspective. I don't necessarily think bad is actually bad, or a better way to put it, there's no such thing as "good" code. What I usually find people calling bad code is just not easily understandable. We as programmers started programming with really comfortable abstractions for easy problems and we expected things to continue like that. When we go into the world of unsolved problems that someone solved and we have to maintain them, and we can't understand them immediately, we call them bad. It's my gut reaction almost every time I'm confronted with something that doesn't immediately enlighten me, even thought I know it's the wrong reaction. We are always comparing everything to the simplest and most solved problems that were easy for us to understand. When it isn't so easy we call them "bad".
- kbenson 8y ago
  Well, there's that, and there's also "bad code" as in "bad engineering", in the real-world sense of engineering. If someone build a bridge quick and dirty and it works for the task at hand, which is crossing some ravine/river, we could all just say "well, it got the job done, so it was good." But when it collapsing due to entirely foreseeable circumstances, and not necessarily because a lot more resources needed to be spent, but possibly just because someone didn't know or didn't care to take the time to figure out the common failure cases, then that's bad engineering. That happens in code all the time. People do things in ways that are prone to problems because either they don't have the experience to know better, or they didn't take the time to think about the domain. I would call that "bad code", no matter how pretty it looks or understandable it is. Part of the problem is that "good" and "bad" are far too vague, so everyone will bring their own meaning. You might see people using "bad" to mean unclear, but I would count that as a sign of progress. A imagine a "bad" mechanical in this day and age engineer is someone that does stuff that costs more money, either now or later when it breaks early, but still produces mostly safe constructs because that portion of the job is highly constrained, and when they fail there, they often aren't just "bad", but may be criminally negligent if they failed to adhere to both the law and industry best practices. If were getting to the stage that "bad" programmers are just ones that write unclear code, that's a huge step up. Unfortunately, I don't think we are there.
- elihu 8y ago
TravelAndFood 8y ago
I expect that most software developers don't spend most of their time designing beautiful, elegant solutions to interesting problems; they spend their time blundering around in an over-complicated and poorly designed code-base using tools that barely work and trying not to trip over myriad corner cases or buried in technical debt. But oh man, when you actually do write that one function that does the cool thing in a neat way and fits into the other crap you're wading around in without breaking anything in a way that makes intuitive sense... man, does that feel nice.
- mythrwy 8y ago
  Putting one more bag of trash on the trash pile without the whole trash pile falling over is a satisfying feeling for sure. And sometimes when it comes to this I feel bad and somewhat guilty. But I can't restructure the whole trash pile and orders and budget constraints and all that, so it just has to keep growing and we shore it up where we can until it starts collapsing around the base and then maybe we can admit it was a trash pile all along and try to do better next time.
matwood 8y ago
> I have a related theory that software development as a profession is starting to increasingly resemble being an air-traffic controller; as the actual programming parts get easier Great comment. This also happens as someone moves up in responsibility. Also of note, I think good code is like a good plan. It's great, until it gets punched in the face. The reality is that most code is written to address constantly changing requirements with a slew of unknown unknowns. And while there certainly is a range from bad to good, what most people say is good will eventually give way to reality of constant change. The best we can do is maintain some semblance of good in this reality. I'm reminded of this excerpt from Musashi: “What a fool I’ve been,” he exclaimed aloud. “I tried to make the water flow where I thought it should and force the dirt to stay where I thought it ought to be. But it didn’t work. How could it? Water’s water, dirt’s dirt. I can’t change their nature. What I’ve got to do is learn to be a servant to the water and a protector of the land.”
- kris-s 8y ago
  So many good lessons in Musashi.

by elihu 8y ago

fmax30 8y ago

What an interesting analogy to make with Air Traffic controllers. Although I still believe an Air Traffic Controller's job is more anxiety inducing and difficult. But the anaology does hold true. My Dad used to be an ATC and he always told me that he actually has fun doing it and loves his job. When I was little I was unable to comprehend how one can enjoy being in such a pressure situation. But now as I am older it makes more sense, as now whenever we are near a major release the pressure is still pretty high but I enjoy writing code and deliverying features too. Even if the code base is really annoying and the architecture of the platform makes me pull my hair out. It still is super satisfying to successfully do a release or when you fix that pesky bug. :)

munchbunny 8y ago

I think that's a good description. As I've become a more experienced software engineer, my job stopped being about making new features and switched to controlling chaos. Writing code that needs to be maintained for years is a very different problem than getting a lot of functionality out the door. Experience teaches you how to adjust for the right spot on the spectrum between "build for business value" and "build for maintainability."

clarry 8y ago
> As I've become a more experienced software engineer, my job stopped being about making new features and switched to controlling chaos. Isn't that funny. Get the inexperienced folk to churn out features so the experienced folk can enjoy the nightmare of perpetually repairing the monster.
- munchbunny 8y ago
  This is why I like code reviews. It let's you make sure it's done with some thought for the future.

systematical 8y ago

This is sadly accurate. Though I do think it's harder to write good code then it is to maintain bad code.

trylist 8y ago

I'm starting to look at it from a different perspective. I don't necessarily think bad is actually bad, or a better way to put it, there's no such thing as "good" code. What I usually find people calling bad code is just not easily understandable. We as programmers started programming with really comfortable abstractions for easy problems and we expected things to continue like that. When we go into the world of unsolved problems that someone solved and we have to maintain them, and we can't understand them immediately, we call them bad. It's my gut reaction almost every time I'm confronted with something that doesn't immediately enlighten me, even thought I know it's the wrong reaction. We are always comparing everything to the simplest and most solved problems that were easy for us to understand. When it isn't so easy we call them "bad".

kbenson 8y ago
Well, there's that, and there's also "bad code" as in "bad engineering", in the real-world sense of engineering. If someone build a bridge quick and dirty and it works for the task at hand, which is crossing some ravine/river, we could all just say "well, it got the job done, so it was good." But when it collapsing due to entirely foreseeable circumstances, and not necessarily because a lot more resources needed to be spent, but possibly just because someone didn't know or didn't care to take the time to figure out the common failure cases, then that's bad engineering. That happens in code all the time. People do things in ways that are prone to problems because either they don't have the experience to know better, or they didn't take the time to think about the domain. I would call that "bad code", no matter how pretty it looks or understandable it is. Part of the problem is that "good" and "bad" are far too vague, so everyone will bring their own meaning. You might see people using "bad" to mean unclear, but I would count that as a sign of progress. A imagine a "bad" mechanical in this day and age engineer is someone that does stuff that costs more money, either now or later when it breaks early, but still produces mostly safe constructs because that portion of the job is highly constrained, and when they fail there, they often aren't just "bad", but may be criminally negligent if they failed to adhere to both the law and industry best practices. If were getting to the stage that "bad" programmers are just ones that write unclear code, that's a huge step up. Unfortunately, I don't think we are there.
elihu 8y ago

TravelAndFood 8y ago

I expect that most software developers don't spend most of their time designing beautiful, elegant solutions to interesting problems; they spend their time blundering around in an over-complicated and poorly designed code-base using tools that barely work and trying not to trip over myriad corner cases or buried in technical debt. But oh man, when you actually do write that one function that does the cool thing in a neat way and fits into the other crap you're wading around in without breaking anything in a way that makes intuitive sense... man, does that feel nice.

mythrwy 8y ago
Putting one more bag of trash on the trash pile without the whole trash pile falling over is a satisfying feeling for sure. And sometimes when it comes to this I feel bad and somewhat guilty. But I can't restructure the whole trash pile and orders and budget constraints and all that, so it just has to keep growing and we shore it up where we can until it starts collapsing around the base and then maybe we can admit it was a trash pile all along and try to do better next time.

matwood 8y ago

> I have a related theory that software development as a profession is starting to increasingly resemble being an air-traffic controller; as the actual programming parts get easier Great comment. This also happens as someone moves up in responsibility. Also of note, I think good code is like a good plan. It's great, until it gets punched in the face. The reality is that most code is written to address constantly changing requirements with a slew of unknown unknowns. And while there certainly is a range from bad to good, what most people say is good will eventually give way to reality of constant change. The best we can do is maintain some semblance of good in this reality. I'm reminded of this excerpt from Musashi: “What a fool I’ve been,” he exclaimed aloud. “I tried to make the water flow where I thought it should and force the dirt to stay where I thought it ought to be. But it didn’t work. How could it? Water’s water, dirt’s dirt. I can’t change their nature. What I’ve got to do is learn to be a servant to the water and a protector of the land.”

kris-s 8y ago
So many good lessons in Musashi.