There are a lot of articles from beginner programmers wondering what programming is like, and I think it’s useful to address those issues. There are a lot of misconceptions about a programmer’s life.
The summary of most of this is that understanding the concept of technical debt is important.
The needs and culture of a company are probably larger contributors to technical debt than individual developer skills. But it all plays an important role in how much the system smells, how much documentation is missing, and what a given developer does in their day-to-day. By understanding the concept one can attempt to mitigate it. But some people may be programming for 8 hours a day, not documenting a thing, and unknowingly increasing the maintenance costs of the system for everyone who will ever work on the system.
These are the most common misconceptions about a programmer’s life:
This is probably the least true of all the things. Most programming jobs are maintenance jobs. The programs have all mostly been written years ago, and you are doing support, minor enhancements, bug fixes. Even if you get to do more than that, you are still not likely coding a large part of your day. It’s about meetings to decide what to do. This is probably one of the most common misconceptions about a programmer’s life.
Also, from my experience, unless you have some reason to dig deep into code (esp. if the code base is large), most people don’t bother. Our codebase is old and rickety. There aren’t any comments. The business process isn’t exactly documented. I don’t want to wade through 2000 lines of Java code (per Java file) and try to understand the business behind it.
Unless you’re working in a brand new project that needs a lot of code written (which I’ve been in), you are probably not doing a lot of programming.
I work at a university. Students, esp. computer science students, complain about our old system that runs a “batch style” programming system. That is, the system shuts down overnight, does a bunch of data processing, and opens again in the morning. They wonder why the system can’t be Facebook or Google or YouTube and be up 24 hours a day.
First, I think many such people would be surprised how many people (or really, how few people) are supporting these systems. You’d think there’s a team of 20 developers doing the best they can to keep this stuff running, and it’s like a well-oiled machine, but sometimes it’s less than half a dozen people, and we barely know the software’s purpose, but can do minor fixes and keep stuff running.
Most software out there isn’t, as they say, rocket science. Sure, a few exceptions (say, SpaceX software). Most of the software encodes business practices, and most business practices are a weird arcane set of rules that have no basis in math or science but is just how some company works. You write that in code, no matter how illogical it is. And often, the code and a few old-timers’ memories are what holds the project together.
Definitely one of the most common misconceptions about a programmer’s life.
Comments? Hah! A written business process? Hah! Programmers had one purpose: get the program to work. They didn’t think about who would maintain the code after they retired. The only saving grace was their background wasn’t so sophisticated as to create true spaghetti code (let’s use regular expressions and finite state machines and design patterns up the wazoo!).
It’s often not the coding language (like Cobol) that prevents modernization (although it’s partly that), it’s that the business process was never formalized, and there are 100,000 lines of code no one wants to read (and only represents an approximation of what the people who wanted the code wanted—and they’re retired too!).
I often point out the scene in the third Matrix movie where the councilman is talking to Neo about how these machines support their underground city, yet no one quite knows who built it or how it works. That’s a lot of software out there.
Writing from scratch is not such a common experience (at least, from my perspective), and even when you do, it’s not always as organized as it could be. We may call it software engineering, but most engineering involves others looking at your work, and having input into fixing it. Code reviews aren’t the same thing as people inspecting a building and seeing it every day.
We often don’t rewrite things because the rewrite would be huge, would require a bunch of new developers, and doesn’t even have the support of the people we’re writing it for.
OK, so you may know to program, but do you know the business you’re working in? Many a programmer or startup guy thinks “You guys do something dumb, and I’m smart, so I can easily create a system that’s 10 times better than the crap you use. And you know what? I’m not even going to consult you about how the system should work. I’ll make up my own. You are such idiots!”.
Well, that maybe, but they’re used to the system they are used to, and they’ve thought about their own (arcane) business process for a long time, and if you build something that is completely different from what they are used to, they won’t say “oh, we lack the intellect to understand your truly great software”, they’ll just not use your software.
If your user base is a bit older, and possibly, even if they aren’t, they will be used to doing things in a certain way. Maybe you can convince them that way isn’t smart, but if they questioned your lack of comments, your lack of coding structure, how what you wrote seems like gibberish, you might get defensive as well. This is also one of the most common misconceptions about a programmer’s life.
The point is that you’re often writing software or maintaining software by those who use the software every day. As a programmer, you might even have the luxury to walk away after you write code, never having used the code as your users use them, and they may ultimately hire someone new who maybe pays attention to what they actually want, even if you think it makes no sense.
Many of you are learning to program. You think companies are willing to throw out a million line codebase because it’s written in an obsolete language. Who’s going to write it? You? (You, Mr. Wineburg?)
A million lines of code is something that could take a lifetime to rewrite. Do you plan to read the code to understand what it does? Could you even do that?
In any case, sometimes people think the program is king (or queen, or some elected position). It’s not.
It’s the data.
Say you’ve run this legacy program for more than a decade. It fills up tables and tables of data. You, being a person who hates legacy code, wants new DB tables, and new ways of storing information.
Here’s the problem. What do you do with all those old data? Oh, you want to throw it out? Start new? Brilliant!
If you look at the world of practicing doctors, they seem to fall (roughly) into two categories: those working in hospitals on patients that need somewhat urgent care (or are doing elective surgery), and doctors with private practices. One of the most common misconceptions about a programmer’s life (and the weirdest one!).
Both seem to follow a similar structure so that if you went from one personal care doctor to another, their structure would be about the same (waiting room, receptionist, files, someone to check your insurance, collect your copay). If you go get your car repaired at a mechanic, you expect a similar experience. If you go to a grocery store, you expect a similar experience.
People in the software industry have nothing close to this. Each company may have widely varying setups. There are companies with just one program that does everything. Could you run a grocery store with just one person? (Well, maybe if it’s a tiny one-person operation selling very few items). Or a doctor’s office (probably not because of insurances, unless you’re some kind of boutique doctor that makes home visits, and even then, I suspect you hire someone to do the billing, etc).
That support structure is often an internal thing, not an off-the-shelf, any small company can do it. If you were a car mechanic and wanted to open your own small shop, you’d probably know exactly what you need (at least, the very basics). These things probably have been (roughly) the same for decades, and even the new things, people probably generally agree on what is needed.
But if you’re a small software shop…there’s no such standards. Do you want to use Atlassian tools? Or do you use a spreadsheet or emails? Do you use some kind of company email? Or do you use personal email? There are lots of decisions, and it’s hardly standardized in the industry.
You may think, say, version control is important. I guarantee there’s some software out there (maybe rare), that doesn’t use standard version control, and it probably does something important. And the people maintaining it may not even understand what version control is and why you need it. I’m serious.
It’s like going to a surgeon with a bottle of whiskey and a bowl of leeches and they say “What’s anesthetic?”
“I know engineers, they love to change things–Dr. McCoy, Star Trek: The Motion Picture”.
Back in the 1990s, the skill most programmers needed? The ability to read other people’s programs. Most early programmers could write code, but they really had a hard time reading code, so they were almost always complaining that you needed a complete code rewrite to write that code in a way they could understand, without realizing the irony that the next programmer would want to throw away their code, and write it from scratch.
Joel Spolsky, who used to blog many years ago (Joel on Software), used to say rewrites were basically evil. A functioning codebase should have been tested many times and many bugs have been removed. A new codebase will introduce new bugs and will be buggy. Software engineers aren’t that good about creating bug-free code (after all, what is a bug? are their specs?). He said it’s better to refactor to improve the code than to rewrite, but most developers like the feeling of an albatross of code of their neck that they don’t care about bugs they introducing.
The new code is wonderful!
But realistically, you need to know what you’re building, and knowledge of the ins and outs of a programming language doesn’t help you figure out what it is you’re building. And sometimes your experts also want to control the kind of software you’re writing (mostly from a usability standpoint).
Many self-taught programmers think “it’s all about learning a programming language”.
It’s hard enough for most of you to learn a programming language. But it’s often the tip of the iceberg. To support web programming, many programming languages have a web framework, and sometimes those web frameworks do a lot of magic, to “help you out”, and now, you thought you understood how a programming language works, but you don’t. (We used annotations, you’ll love how it’s not crufty like the rest of Java!)
There are a lot of misconceptions about a programmer’s life which can have a negative impact on someone’s choice of career.
You don’t program hours a day unless it’s brand new software, and even then. You’ll probably spend as much time in meetings (if you get to be important enough) than programming.
There are generally two kinds of developers that survive in a company/organization that’s been around awhile: those with strong technical skills, and those that have been around long enough to understand how things work (business-wise) even if they lack the technical chops. Sometimes (rarely), they are the same person.
You don’t need to know computer science that well to write software that basically works, esp. if you know the business well. A lot of software may require only basic math skills and some understanding of how the web works. It’s sort of the equivalent of a doctor that learned how to doctor online, and only learned 10% of what they should. They may still be able to heal most basic things, but not be able to do some other basic stuff. We don’t trust that in doctors, but in software, it might be OK.
Knowing the business is often at least as knowing the software, possibly more important. Your customers likely don’t want you to make “improvements” to their software, esp. those that you didn’t bother to consult them with.
You often have to teach yourself newer technologies. Your senior developers aren’t usually willing to be teachers and teach you from scratch.
Communication skills are useful, but most developers became developers because they prefer to work alone. This doesn’t always lead to good software, no matter how skilled the person is.
You shouldn’t think you’re writing code for yourself, but for the next person that has to maintain it. Don’t be too clever. Someone else will have to deal with your code (and it could be you, two years later). Maybe write some comments or something.
The software can be developed in all sorts of ways, many not approaching “best practices” (which seems to change all the time). Not everyone is on the cutting edge (see New Jersey Cobol programs for filing unemployment). Being on that edge requires chasing a moving target that most companies think is a waste of time (why does Spring keep coming out with new versions–haven’t they figured it out by now?). This means that there is no typical way software is developed. Yes, many companies share similarities (they have a Wiki, they use Jira, they use Bitbucket, they have a deployed system, they do code reviews), but it’s not universal.
Your code is often not reviewed as much as it should, and you might get defensive about the comments you get. Code consistency helps (if you can tell who wrote the code based on stylistic choices, that may not always be the best thing).
This is in our opinion the full list of the most common misconceptions about a programmer’s life.