Software Engineer
A tough but financially rewarding job, if you can be a shut-in with hyper focus, and slog through the tedium of bugs.
~ Aristotle Sabouni
Created: 2003-01-01 |
Many people have asked me over the years about Software Engineering; what's it like to be a computer programmer? They see the glamour of the job (believe it or not), or hear about the paychecks, without seeing the downsides. There are many positives to the job; because it takes a lot of knowledge to do well, so there are few that will do it. And because it requires thought and continual learning and change, there are fewer that can do it well. So getting a job that's in demand and hard to fill, generally means reasonable salaries and relative security (compared to other jobs); and there are many companies looking for people.
There are also many downsides to the job and I'll mention many of them... not to discourage people, but so they can think about the job with their eyes wide open. I don't think this career has it worse than many other careers, which also come with their share of the problems; but I do think there are many problems that others don't know about.
Image and real life[edit | edit source]
Most programmers go into the career path with visions of creating new things. Software engineers often have an artist streak (or think they do), along with a bigger streak to control and order the universe as some cathartic way... probably to make up for all the pressures and injustices done to them as teenage nerds. In typical fashion, the world doesn't choose to let them have that level of satisfaction. Many get stuck on legacy products, and there are so many people that you need a lot of processes -- and then you're constrained from creating as much by the process (because everything needs to work with everything else, and even look like everything else for how it is written). For each new product or project, there are 100 existing products that still need support, coding, and new features added. And the older products are usually bigger and have more people on the projects. If you do the math, you can guess where most of the programming jobs are.
Shit rolls downhill and newbies in any industry are the valleys. So new programmers get all the dirty jobs and projects that no one else wants. This means that they don't get to create new things; they inherit and get to fix other people's bad code. Not only that, they usually get to fix the old things that are so bad that the other programmers don't want to get near them. This just pours on the job satisfaction. To the average programmer, it's like taking a classically trained artist and making him paint the interior walls of public restrooms. Beige... all day long.
Most programmers I know never went into the job thinking, "I want to try to decode and fix other people's garbage all my life", yet that's what many do. Those few that are getting to create things, are not left alone to do their jobs and actually create, they are beholden to marketing and management who will "prioritize" what features they get to work on and when. This is like telling them, "take your 10-20 years of experience and knowledge and flush it down the toilet, and listen to me, because I once read a technology magazine or talked to a customer and think you should be doing this". Most managers or marketing people want to win; which isn't about making the best product or making money or what the programmers care about; it is usually about getting their way no matter how lame or impossible that is.
<well>This was from the 1970's to the early 2000's, Since then it's often more boring: a lot of the job can be hunting down the right libraries or tools to add to the code, then just getting it to compile, and using that for a lot of stuff. Which can be even more boring, since instead of coding, you're just analyzing or integrating: the go between, stuck between things that other people have written. </well>
What do you do?[edit | edit source]
One of the toughest aspects of Software Engineering is that people don't really know what you do. They get that you "program computers", but most don't even know what that really means. Many think that programming an accounting program, writing a device driver, or doing a game is all the same job; when these are radically different disciplines, each which can take many years to master, above and beyond the general knowledge. Many programmers have to be so deep down into one area of a 20 or 100 person project, that they don't even have a clue as to how their whole system works. This is like an airplane designer whose specialty is landing gear wheel bearings, he may or may not know anything about how the actual plane works -- and all the math and things he's doing has absolutely nothing to do with keeping that aluminum can in the air.
Strangers or friends and family not understanding what you do, isn't that big a deal. Yes, it is annoying when they find out that you're a computer programmer, that they try to have you help them fix their home computer that the dog urinated on, or to fix their machine after they installed 27 pieces of malware they got from Internet porn sites. As if somehow doing computer repair or IT (support) is vaguely related to programming a satellite or whatever it is you do... but hey it is all technology and computers, right? However, while that is annoying, it doesn't affect your livelihood or stress level compared to the other things.
The real issues is that most people in your company, especially the decision makers, don't really understand what you do.
Think about that; about 95%+ of the stress in a programmers life is that people don't know what they do, or how they do it, telling them what to do, and how to do it.
- Most Human resource people that are hiring programmers, and filtering Resume's, don't understand what they're doing or what the people do. So they can't figure out that someone that's been doing something on one platform for many years can easily apply that knowledge to another platform. Getting past inhuman-resources becomes a game, sort of like being thrown to the lions in Roman arenas was just a game.
- Even when you get past the roadblocks to get the job, most Management doesn't understand what programmers do. So they think of programmers like widgets and resources. If we fire these 10 programmers, and move these 3 over from another division, then they balance the resources better. They don't begin to grasp the differences in expertise, or that you can't replace 10 device driver writers, with 3 Database programmers and get a reasonable outcome. They look at things like pay rate or location for who to hire and fire, and not abilities or disciplines. And the last thing in the world they want is some peon programmer trying to explain to them why their great idea is a bad one.
I've seen company after company make horrid management decisions, eliminate 80% of the core competency and knowledge in a company in a cost cutting measure, and then drive out the remaining 20% by trying to force round pegs into square holes; and blame the pegs for the poor fit. There's a joke that Dilbert (the comic strip) is life; but that's not completely true - Dilbert and Scott Adams aren't cynical enough for the real world. Seriously, if you can't read Dilbert, and picture yourself in that world and laughing at what's going on around you, then you should consider a different career path.
- Managers often don't understand schedules; they were taught the Attila-the-hun management system and have a "black belt" in marketing and sales. So they think if they push harder, they'll get more out of engineers. They fail to realize that while they get more features in less time, they increase risks, decrease quality, documentation, and maintainability. (You can pay up front, or pay much more later on). But those failures are not managements' problem; engineers will get blamed for that scheduling snafu later.
- I can't stress this enough; a complete lack of understanding about engineering or what it is engineers are doing is not going to prevent management from making decisions and trying to micromanage the engineers themselves, and get mad at the engineers for not being able to do the impossible. Get over it.
Many programmers can't get over the stupidity... and go job to job looking for utopia; or at least the fictitious job where complete incompetence is not the norm. It doesn't exist... or at least not for long. Sometimes you can find good lower level managers that can shield their people... for a while. Or there's a rare project that's making so much money, that they don't mess with the team for a while. But then eventually business starts trying to control things more, and it goes back to the know-nothings trying to tell the know-somethings how to do everything.
Those looking for where the grass is greener are usually continually amazed that things can, and do, get worse from their previous jobs.
I have people from many different companies whine about how their management sucks worse than anyone else's; then someone tells them stories about places they've worked or decisions that are made, and there's silence while they process that. Four programmers around a table can quickly devolve into a game of, "my management is more stupid than yours". Then, "Oh yeah..."
The sad thing about human nature is that you cannot over-estimate how low it can go. Sadder still is this is in America, one of the most effective and productive nations in the world. Many foreign countries have even more bureaucracy, hierarchy and stupidity.
Peter Principle[edit | edit source]
The Peter Principle states that people rise to their "level of incompetence". Which means you succeed and rise until you fail, and then stay there indefinitely, being incompetent and making others miserable, but being unable to rise further. Engineering works like that too.
Imagine this; you are a good and competent engineer, which usually comes with certain skills:
- the ability to focus to the point where you ignore the anarchy around you.
- the ability to ignore managements' mandates, while still duping them into thinking you're listening (following them is the sure road to failure)
- you probably also have the interpersonal skills and hygiene of a rabid wolverine (why waste useful synapses on such trivia that could be better used remembering variable names or archaic concepts about operator overloading and constructor precedence).
Since this person has demonstrated that their work is more important than their personal life, or life in general, and they've succeeded in spite of all the attempts to be helped to death by management. Since they've proven they are unmanageable, they are an obvious leader. They will either be fired, or put in charge of a team of people... based on the scientific "eenie, meany, minie, moe system".
Take a minute and digest that: the skills required to effectively manage a team of people well are diametrically opposed to those of succeeding as a software engineer.
- Engineers need to focus on one thing in-spite of the chaos around them; managers need to defocus and pay attention to their surroundings.
- Engineers often like to control and micromanage a computer, Managers need to not try to control everything and learn how to delegate and how to motivate people, not just force them to do what they want like they are computers.
- Engineers are often completely insensitive to social norms and focusing on the task and got into computers because they are sick of humans, management is about being sensitive and empathetic and helping others to focus on their task, usually to the detriment of your own.
So the recipe for a good engineer is the exact recipe for an arrogant and caustic control-freak of a manager or team lead.
Thus there are a few (very few), team leads or engineers that clawed their way up the ranks and have both sets of skills, and know when to use them. Most are just people who followed the peter principle and are now an obstacle to everyone around them.
Of course not all managers are like that. The other common type of leader is the ex-engineer that wasn't very good at all, but realized that quickly, and made a name for themselves as being a yes-man brown-nosing sycophant that knows politics and finger-pointing better than the other asocial engineers, and got to the top through conniving and treachery. These people are often destined for great things. They like to take credit for other people's work, blame others for decisions they made, and they love to "help" the real engineers by coding over their shoulder with suggestions that can't actually work.
The lesser managers will often drive out the good managers because the evil and incompetent managers quickly realize a threat... and if they can agree on only one thing, it is eliminating threats. So they can get back to their one true love: the cruel torture of damned souls beneath them.
Conclusion[edit | edit source]
I've read a few places that the average "lifespan" of a computer programmer is about 7 years. Now they were talking about career-wise, but I wouldn't be surprised to hear of programmers driving into walls or jumping off tall buildings either. But what that 7 years mean is that programmers spend 4+ years of school to learn how to program, and at least that many years learning on their own, all to get a "career" that lasts about the same length of time as their learning. Imagine Doctors only being able to tolerate their job for 8 years, and you get the picture.
Now most programmers shift out of programming into other technical career; usually they go into technical management, technical sales, support, IT, a padded cell or prison. Often something technical.... but where they don't have to deal with the frustrations of coding 70 hours a week for idiots that don't appreciate what they do. Not because they don't like coding, but because they can't take what goes with it.
The purpose of this little rant is not to bum people out, or scare people away from a career in programming or software. A few make it a while. I did over 25 years before shifting into full time management. Many of those other paths that people can go into are built on the knowledge and experience they got the hard way through programming. Experience and wisdom is what you get when you don't get what you want; and programmers get a lot of experience. So those few that escape with their sanity are better humans for it.
If you go into programming knowing what it is like, it can help you to prepare. Or if you have a conversation with some programmer, instead of thinking they've got a cushy job with great pay, you can empathize a little... or begin to grasp the stresses they might be living through.
🔗 More
| |
| |
