True story.
I almost deleted this chapter from the outline of the book.
Really. I looked at it and said, “types of work,” what does that mean?
At first I was thinking that I meant the kinds of jobs you could have as a software developer and I recall already covering most of that in earlier sections of the book.
But then it hit me. Duh.
Software developers do a lot more than just write code.
There are quite a few different “types of work” that software developers do.
And guess what?
You need to know about them.
I mean, I couldn’t exactly call this section of the book “What You Need to Know About Software Development” if I didn’t actually tell you what you were going to do all day at your job.
Heck, you might get the crazy idea that you’ll spend all day coding.
Imagine how disappointed you would be if you showed up at that corporate gig all ready to spend eight hours writing code like a madman only to find out you might only get to actually write real code a few hours a day.
That’s what this chapter is about––a reality check.
If a software developer doesn’t write code all day, what, indeed, does a software developer actually do all day?
Let’s find out.
Writing Code
Wait, what? I thought you just said software developers don’t write code all day?
Yes. That’s right. But they do write some code.
I mean, would you really call yourself a programmer if you didn’t actually program? It’s just not as much as you think––at least most days.
You can definitely end up going on a code writing binge and code like a madman for several days and nights, living on Mountain Dew and Hot Pockets. (I have to throw the cliché into every book I write.)
But, in general, most days, you do not just simply write code. There will be many days where you don’t write any code at all.
Those are sad days, but necessary.
The general rule is, the smaller the company, the more code you are likely to write in a given day.
The bigger the company, the more overhead there is going to be, and the less time you’ll spend writing code. That’s just life.
But, you’ll definitely spend some time writing code.
I won’t explain what writing code entails, because if you don’t know, well… I’m not sure I can help you.
Fixing Bugs
Ha! Sucker!
You thought you were going to write a bunch of new code and use the latest and greatest JavaScript framework, but instead you are fixing bugs.
Sometimes you get to write new code, but more often than not, you get to fix bugs in old code––again, life.
Software developers write code, that code is not perfect, it has bugs in it.
Someone has to fix them. That someone is you.
Check out the chapter on debugging to learn more about how to do this effectively, but just know that a decent portion of the time you will spend working in code during the day will be spent fixing bugs, both your own and others.
Design And Architecture
This is actually a pretty fun non-coding part of being a programmer, because you get to use your brain, draw on a whiteboard, and argue with people.
For some reason, programmers really like to argue with people and to yell.
True story. I was once accused of throwing a chair at a Quality Assurance person.
I didn’t actually throw a chair.
I accidentally knocked it over while having a heated discussion.
But, you know how rumors are.
There is a pretty good chance as a software developer you’ll spend some amount of time working with your team––or by yourself––to develop the architecture or design of the system you are working on.
Most software developers don’t just jump straight into the code and start coding something up.
Ahem. Let me correct that.
Most great software developers don’t just jump straight into the code and start coding something up.
Instead, they spend some time designing out what they’ll be coding ahead of time and arguing with other nearby developers about why one way of doing something is .01 percent better than another way.
You’ll spend a good amount of time working on some kind of design or architecture activity in your tenure as a software professional.
Meetings
Yes, I hate them too, but sometimes they are necessary.
I was pretty notorious for skipping meetings as a software developer, when I didn’t find them important.
I still do that.
I don’t like to waste my time.
But, the truth of the matter is that no matter how much you despise meetings and try to avoid them, you’ll likely get sucked into at least one or two during your software development career, perhaps even a daily or weekly one.
You are just going to have to get used to it and realize it’s all part of the job.
You might wonder why a software developer would need to go to any kind meeting at all.
Well, sometimes I do, too. But there are actually some legit reasons.
If you are following a process like Scrum, it’s important to have a planning meeting to plan out and estimate the work which will be done in the Sprint.
Retrospective and review meetings are also important for demonstrating work, getting feedback, and making improvements.
Sometimes important project-level decisions need to be made and having a developer in that meeting, who understands the technology, can be an important part of making the right decisions.
All in all, expect to at least spend some time in meetings in your life as a developer.
Learning
I often get asked if software developers should be paid to learn or if they should do it on their own time.
The answer is “yes.”
You should be learning while at work, but you should also be doing it on your own time.
It’s pretty naive to think you can work at a software development job and not spend at least some of that time learning.
When I worked as a software developer, I would spend the first 30 minutes of my day browsing software development blogs and keeping myself up to date.
Doing this allowed me to do my job better and to better understand the industry.
In fact, one of the first––and most important––interview questions I ask potential candidates is how they stay up to date.
I’m actually looking to hear that they dedicate a certain amount of time each day to reading and learning to keep their skills sharp and get a heartbeat on the industry at large.
You’ll also need to learn on the fly when you encounter a difficult problem at work, which will be pretty often.
You’ll spend quite a bit of time at work Googling for answers to your questions, reading tutorials, and even going through books to help you solve a problem, design a solution, or learn to use a new technology in your job.
Some software development environments actively encourage learning, while others try to milk developers for every ounce of productivity they can and tell you to “learn on your own time.”
Good software developers can’t do their job without constantly learning, so learn you will.
Experimenting And Exploring
This is sort of learning, but a bit more than that.
In order to do your job effectively, you’ll find that you need to spend a large amount of time reading through existing code in the codebase to understand what is going on and to know where and how to make changes.
You’ll also find that you need to just “try some things.”
You’ll want to write up a sample program to try and use a new API or technology that you are going to utilize to implement a new feature or fix a bug.
You’ll want to play around a bit with technologies and tools to figure out what will work best for the problem you are trying to solve and to get familiar with them.
You’ll likely prototype certain features or functionality before you implement it in production code.
Expect to spend a good amount of time doing these things, especially when working on large systems with complex codebases or implementing new features with new or unproven technologies you may not be familiar with.
Testing
At the very least, you’ll spend a good deal of time testing your own code. Or you might help out by testing in general or working on writing automated tests.
Testing is an integral part of software development and good software developers make sure they test their code before they check it in and distribute it.
See the chapter on testing for more about testing in general.
Some software developers really hate the idea of testing–they think it is beneath them.
They think it is their job to write the code and then the testers job to test it.
This isn’t true at all.
You, as a software developer, should be responsible for the quality of your own code.
You should spend the extra time to test, to the best of your ability, your own code to make sure it works correctly.
Only after you’ve tested the code, should it go to QA for further testing, after you’ve found––and fixed––all the bugs you can.
Thinking
I swear, sometimes software development is more thinking than anything else.
I often sit at my desk for long stretches of time, apparently doing nothing, but really just thinking, thinking, thinking about how to solve my problem or how to structure my code.
In fact, you really should spend at least at least three times more thinking about the code you are about to write as you do actually writing it.
It’s that old saying, “measure twice, cut once.”
Even though code is highly malleable, it still pays to get it as close to right the first time as you can.
You can save yourself hours of rewriting and debugging if you spend a few extra minutes thinking about a solution––and thinking it all the way through––before you implement it.
It can be tempting to think that thinking isn’t productive and that it is a waste of time just because you can’t see tangible results from it.
I fall into this trap all the time.
If you feel this way, sometimes it helps to have a notebook that you write your thoughts in as you are thinking about solutions to your problem, giving you a physical artifact of your thinking
And it can give you something to fall back on when you wonder why you did something a certain way and can’t remember the thought process that got you there.
I’d probably be willing to go on record to say that the most effective software developers will spend more time in their day thinking than anything else. And I guess I just did.
Interact With Customers / Stakeholders
This can suck. I know.
And you might not be good at it.
But you are going to have to do it and you might as well get good at it.
Start by reading How to Win Friends and Influence People, and if you haven’t read my book Soft Skills: The Software Developer’s Life Manual, you should probably do that, too.
But why, why John, do I have to talk to customers and stakeholders?
Can’t I just sit in my cubicle and write code and let the business people deal with everyone else?
Yes, you can.
You can absolutely do that.
But you are going to extremely limit your career and your potential.
We no longer live in a world where software developers are valuable just because they can write code.
The skill of writing code is being commoditized.
You can find coders all over the world who can write code for cheap.
The value of a software developer today is not just the ability to write code, but to communicate and translate the requirements of the business or customer into the ultimate technical solution.
If you want to be a good developer, you are going to need to understand the requirements of the system you are building.
That means you are going to have to talk to customers or stakeholders and understand the problem domain and the problem you are trying to solve for them.
This is especially important in an Agile environment where you are constantly iterating on the software you are building.
Expect to spend some time each day, or at least each week, talking to customers or key stakeholders and actually communicating.
Training / Mentoring
The biggest value of an experienced software developer, for a team, is not his or her individual ability to write code.
Yes, a really good programmer can do the work of perhaps as many as 10 not-so-good programmers, but the impact is still limited in comparison to the effect a really good developer can have on raising the ability of the entire development team.
As you gain experience and become better at your job, you’ll spend more and more of your time training and mentoring other developers.
This is a good thing, although sometimes it can make you feel not productive and make you yearn to write more code.
But it is very rewarding to know that your contributions to a team and to the community extend beyond your personal abilities to write code.
And That’s It…
Well, mostly.
There may be some other jobs you have to do as a software developer, depending on where you work, like setting up servers and perhaps even selling to customers, but we’ve covered most of the basics here.
And that actually brings us to the end of this section of the book, so now it’s time to get to work.
In the next section, we’ll be focusing on how to survive and thrive in the work environment of a typical software developer.
Journey on.
