I’m told there are workplaces where large, skilled software engineering teams follow textbook development processes and efficiently produce reams of high-quality code. I’ve never worked at a place like that.

The rest of us are stuck dealing with:

• small teams lacking practical software engineering experience
• big, ugly legacy code bases
• having to write code in between meetings, PowerPoint, and other job responsibilities, and
• engineering processes ranging from “loose” to “non-existent”.

This is a dangerous world for a new coder. It’s easy to develop bad habits. Ultimately, it’s up to you to keep pace the larger software engineering community, and this extra effort pays off when you look for your next job or project. There are tons of books and blogs about software engineering. But here are the three most important things you can do to improve your value as a software engineer:

1. Write automated tests for your code.
Every language has one or more popular testing frameworks (like JUnit for Java and Nose with unittest for Python). Back in college before I learned to write unit tests, I would write a quick script or modify the application to print some debugging information. That’s how I would verify that some new function or class was behaving properly. Unit testing formalizes this process. The biggest benefit is that you build up a collection of these tests that you can run again later. This helps squash bugs caused by new code breaking older code. Even if no one else on your team is writing automated tests, you can and should write test cases for your work.

2. Use revision control for your source code.
Source code revision control systems let you commit code changes to a repository and preserve a revision history as your project evolves. They’re pretty much a necessity when coding with a team. It doesn’t matter which one you use, but be warned that a lot of developers are seriously attached to their system of choice. Subversion is really easy to learn, so I’d suggest starting there. Git is what I use now, but anyone that tells you it’s easy to learn is a lying liar. A less obvious benefit of using source control is that you can delete old code without worrying. You can always get it back from the revision history. Uncluttering your project makes it easier to work on.

3. Learn some important design patterns.
Breaking down your project into a class hierarchy can actually be pretty fun. There are lots of design patterns you can follow to decompose your problem. I’ve found these two to be the most helpful for small projects: Composition (often a better option than traditional inheritance taught in introductory programming classes) and Dependency Injection (DI). Despite a scary-sounding name, DI is a very simple design pattern that helps you abstract out dependencies on libraries and services. If you’ve ever had to change the database you’re using, for example, you’ll immediately see why this is a great technique.

And one last bonus tip: write less code! The great Edsger Dijkstra teaches us to think in terms of “code spent” rather than “code produced”.