A friend, who is just starting out in software development, asked on Facebook yesterday: “What would you tell your past self just starting out in your career? What mistakes did you make that you learned the most from?”.
I think this question can be answered in three parts: technical skills, non-technical skills, and general advice.
If I was able to tell my “past self” a few things that I should have learned much earlier than I did, they would be the following (in no particular order):
- Version Control (aka Source Control): Learn how to use a version control tool, probably Git. (Aside, my source control history went from VSS -> TFS -> SVN and then to Git). It doesn’t matter if you’re starting out as a solo developer, or jumping in as part of a team, learning to use these tools properly will make your life much easier. Start with the basics: creating or cloning a repo, committing changes, and merging branches.
- Testing: Write tests for your code – both unit tests and integration tests. This won’t be obvious when you’re starting out. “Well, my code works” you’ll think, “why do I need to spend all this extra time writing tests?”. You won’t yet understand how somewhere down the line you’ll make a small change that will impact a part of your product you’d forgotten was related. Being able to run tests will save you from future headaches and embarrassment. Operating systems and web browsers will change over time, breaking your code. Tests will find this quicker than you will.The unexpected advantage to writing tests is that you’ll also be learning to write testable code. Code that’s easily testable is by nature better code. You’ll learn to write functions that are more efficient, simpler, and easier to read.
- Coding Standards: Whether you’re the only one working on your product’s code, or whether you’re part of a team, learn a coding standard for the language or framework you’re working with, and stick to it. (I do a lot of work with WordPress – in those projects, I follow the WordPress Coding Standards). You’ll learn to write code that’s easier to understand by naming things in a consistent way and by laying out your code in a consistent way. This will help prevent a lot of errors in your development process, it will help you maintain your code in the future, and will help others who may be working on your project. I love the quote: “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” (source: code for the maintainer)
- Code Review: Adopt code review processes. The value of a second set of eyes on your work is unbelievable. I’ve had mentors and colleagues over the years who, on many occasions, would spot something in my code that just didn’t make sense (either wouldn’t work, was over-engineered, wasn’t efficient, etc.). I would do the same for them. Code reviews are not a review of your skill as a developer, but part of the process of making a better product.
Equally, or maybe even more important than the technical skills are the non-technical things that will make you a better developer. Again, in no particular order:
- Learning to speak in non-technical language: Learn to explain technical issues to non-technical people. This will be invaluable if you have to speak with clients, users, or other stakeholders in your products who don’t understand code. It will help make sure everyone is “on the same page”.
- Estimate Your Time: This is an area I’ve always struggled with, “how long will it take to do X ?”. Here’s a hint – longer than you initially thought. Learning to properly estimate your time will help you whether you are a freelancer quoting a job to a client or an employee who needs to tell a manager when a bug will be fixed. Learn to leave enough time for writing tests (see above), doing code reviews, documenting, etc.
- Participate in an open source project: I’m calling this a non-technical skill, as being part of the open source community may involve writing code, but there’s so much more to it than that. Participating in a project will introduce you to a community of like-minded individuals. You’ll find developers who can help you grow professionally, and you’ll help others grow. You’ll learn to work as a team. Any code you write will be available for all to see and scrutinize, which will force you to write better code. In software development, you’ll take a lot – free software, answers on StackOverflow, libraries from package repositories, etc. Participating in an open source project is a way to give back.
To quote the 90s song Everybody’s Free (to Wear Sunscreen) by Baz Luhrmann:
“the rest of my advice has no basis more reliable than my own meandering experience”.
- Never Stop Learning: I spent 15 years working for the same employer. For most of that time I was maintaining the same application. The problem with this was that I used the same technology stack, and the same tools. When it came time to change jobs, I found the world had moved on from those tools, and there were many things I needed to learn just to “catch up” to what everyone else was doing. Don’t get comfortable with only doing one thing. Stay curious, dabble in what’s new. Have “side projects”.
- Don’t be afraid to break things: Software is just zeros and ones. Learn how things work. Look at other’s code – change it, see what happens. Try things until you get them working. Experiment.
To the other developers out there… what would you have told your “past self” ?
Ditto on the version control and estimates! Estimates are still something I haven’t completely mastered, but it’s just as you said, “longer than you think” haha now I just naturally think of the hours I think it’ll take and add extra hours on purpose expecting something to go horribly wrong. Better to overestimate and be under budget than the other way around. 😀
I’d also tell myself to have more confidence – another thing I still struggle with and I think we all do as developers at times. Be eager to learn and never be ashamed of not knowing something, see it as an opportunity.
Thanks for sharing this post.
On the “Never stop learning” side of things, I’ve recently gotten into the habit of doing mental exercises in down time. For example, if I’m waiting in line somewhere, I’ll pick a random decimal digit and try to convert it to hexadecimal by way of binary in my head as fast as possible, or figure out the simplest recursive solution to a geometric sequence. Doing the former has made me lightning quick at changing bases in my head, allowing me a bevvy of base-specific math tricks at my disposal (like two’s compliment), doing the latter has made many complex operations much simpler. It’s been such a simple thing to strengthen my comprehension that I wish I had started doing these exercises 10 years prior.