You can’t work in this business for very long before the hope, idealism and intellectual curiosity is beaten out of you and replaced with TPS Sheets, and 15 different tools for telling your colleagues how to configure IIS so that your app will actually run on their machine.
If you’re new to this business there may still be time to save yourself. Go drive a truck, or learn a bit about your city and become a tour guide. On the off chance that you are determined to stay in software development here are my top 5 mistakes, maybe you can avoid some of them.
5. Thinking that things I am unfamiliar with are Bad
Us software developers generally have a well cultivated sense of your own ability to reason about things without actually trying them. We are professional generalisers after all.
“I don’t need to install Linux to know it’s shit”
“LINQ is unreadable”
“No, I don’t use ‘var’ I need to know my types”
At one point I had very strong arguments against var. A colleague tried to make me see the light but couldn’t. Then one day, Eureka, I got it. It was never about ‘var’. In my head the debate was “Save a few keystrokes, at the cost of not having the types in your face”. I thought I needed the types and saving keystrokes wasn’t a priority.
What I didn’t get was that getting rid of the in your face types wasn’t the price, it was the point. The saved keystrokes were incidental. It was never about keystrokes, it was about abstraction. In the same way LINQ wasn’t about writing LESS code, it was about writing code at a higher level of abstraction.
This is different from the static vs dynamic types debate which is a whole other issue, but I know now that I don’t know enough to have a very strong opinion on dynamic types.
Before you reject something as useless or bad, make sure you get the point. Your preconceptions about why a technology exists might be a million miles from the reality.
4. Thinking that things I am familiar with are Good
This is the flip side of the point above but in many ways it’s more damaging. We have a tendency to think the things we are familiar with are the solution to every problem. You can waste a lot of effort and creativity trying to figure out how to press flowers with a hammer because a hammer is what you know.
3. Thinking there’s a right way
When I started building software I was convinced there was a right way to do it. If I could figure it out I could carve out a nice career following my process.
There is no right way. Give up on finding the best way to build software, or even dividing processes, tools, techniques into Good/Bad. It’s wasted effort. One persons good technique will sink another person’s project. One person’s horrible hack will save another person’s project.
2. Thinking that I could learn software development from books
spent wasted so much money on books. I recently threw a lot of them away. In my defense when I was learning this business the internet was in it’s infancy and there wasn’t a huge amount of curated material out there. Books were how it was done.
Even still, I bought far too many.
I did read a lot of them and I learned a lot from them but I didn’t learn how to develop software. I learned some ideas that could be applied. I could have saved a lot of money by not buying and a lot of time by not reading quite so many books. I could have spent that time actually building more software and more varied software.
Blogs, Screencasts, Online Training are the new Books. I think there’s a danger of replicating similar mistakes, spending too long thinking about software development as a theoretical pursuit, and leaving too little time to build stuff.
You’re making this mistake right now. You think that maybe there’s some insight here that will make you a better software developer. There probably isn’t. Go write some code.
Hey, at least you didn’t spend 40 $/£/€ to be here.
1. Thinking it all someone else’s fault.
If you work as a software developer you will work on a lot of teams and unless you are really lucky, most of them will be terrible. At least they will be terrible from your perspective.
Most software development is terrible. It’s frustrating, it’s unreliable. It’s difficult. It’s tedious.
It’s easy to assume that this is all someone else’s fault. There are solutions if people would just adopt them.
There really aren’t. Everyone including you is trying to figure out how to build software and make things less frustrating. The problem is that one person’s solution is the very thing that frustrates the hell out of you. And it works both ways. Do you have any idea how frustrating it must be for a project manager to have a coder tell them that estimates are useless.
I’m fully conscious of how frustrating it must be to work with me.
I don’t have any magic answer on this point other than to realize that none of us really have THE ANSWERS. It’s probably better to have a team full of people who know that then a team full of people with their own ideas, all of whom think they are right.
Of course there’s no point recognizing this fact if no one else on the team does, so you may have to take yourself out of that situation, and look elsewhere, but at least you’ll know what you’re looking for.