I see frequent posts from beginning programmers wondering what programming is like, and I think it’s useful to address those issues.

You program 8 hours a day at work

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.

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 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.

A program is about 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.

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 fix 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.

As a programmer, since I wrote the code, my opinion is the most important

OK, so you may know programming, 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 may be, 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.

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 a 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.

The program matters

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 table 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 that old data? Oh, you want to throw it out? Start new? Brilliant!

Every software shop is the same

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.

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 programmer 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’re hire someone to do the billing, etc).

The big companies can afford to have their own internal support structure that makes it easier for their average developer to deploy code. 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 anaesthetic?”

We’ll rewrite everything!

“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 there 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 off their neck that they don’t care about bugs they introducing.

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).

I only have to understand a programming language

Many self-taught programmers think “it’s all about learning a programming language”.

Some complain: why do I need to know HTML? Why do I need to know CSS? Why do I need to know SQL? Why do I need to know version control? Why do I need to know Github? Why do I need to know math? Why do I need to know business? Why do I need a deploy system? Why can’t someone else test my code? Why do I need a bug tracking/task tracking software? Why do I need to read my emails? Why do I need to update my tickets?

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!)

Conclusions

  • 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 a while: 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.

  • Most people tend to do maintenance programming, not green field (brand new) coding.

  • 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.

  • 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 deploy 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).

Credit: https://www.reddit.com/r/learnprogramming/comments/gtcwn4/the_misconceptions_of_a_programmers_life/