Programming is a team sport. To be sure, there are times in my career when I’ve locked myself in the room and spent weeks writing software. Even a very complex piece of software like Avalara’s AvaTax API can be written by a single programmer in a few months, but only because I had a team supporting me.
Software engineering is about problem solving. In my experience, successful software engineers spends 80% of their time researching problems, and only about 20% of their time writing solutions. When I research, I need advice from colleagues, documentation, example code, and StackOverflow.
Be a Team Player
I have regularly been called on to integrate some complex piece of software, or some complex toolkit, or some new technology acquired through a merger. It doesn’t matter how great I am at hashed dictionaries, binary trees, or sorting technologies; my real value sometimes comes from being able to read poorly written documentation and figure out a solution through copying and pasting messy example code.
So my first piece of advice is: Be the kind of person that others want to help. Your team is called a team for a reason, and the kinds of skills you learn playing on a pickup soccer team are valuable for programmers! You need to pay attention to your teammates when they have something to share, to be considerate when someone is frustrated, to motivate a colleague who is down in the dumps, and to constantly challenge each other to do better.
These team-oriented skills are easy to overlook, but valuable in practice. It’s important to know algorithms, but it’s also important to help and be helped. The perfect sorting algorithm can’t make software successful on its own. Your team is there to help guide you as you start out, and the most successful new hires are generally the ones who get along well with their team.
Learn How, What, and When to Optimize
I’m often asked to look at a piece of code and see if it’s optimized. Many new engineers assume that they are being judged on some invisible and ominous metric of code performance. I think this illusion comes from textbooks that have an answer key for each question on a homework assignment, but I want to encourage you to try a different approach.
What does “optimized” mean?
- Are you optimizing for runtime?
- Memory consumption?
- Thread count?
- I/O usage?
- Sharing development work across teams?
- Cost of execution on a hosted platform?
- Reusability?
- Porting across multiple platforms?
- Time-to-market (or speed of development)?
- Resilience to unexpected failures?
- Maintainability?
Problems like these are why premature optimization is the root of all evil. Until you know what you need to optimize, don’t optimize.
During your career, you’ll write code that must be fast. You’ll also write some code that is quick and dirty; some code that automates something that annoys you; some code that your manager demanded even though it seemed like a bad idea; some code for a feature requested by a client that only they will use; and some code that works around a flaky network connection or a bad device driver.
Each of these pieces of code has a different purpose and a different challenge to overcome. Unless you’ve been specifically requested otherwise, your code should be simple, clean, and easy to understand.
Your code should have comments and human-friendly variable names. Your functions should each have a clear purpose and should be small enough that you can read it without scrolling your screen. You should use the simplest possible algorithm. Simple code is easy to optimize later!
Sustain Your Career
If they ever existed, the days when a programmer would be employed by the same company for life were long gone even when I started my career. There is only one person who will take care of your career for you—and it’s you.
The good news is that you have lots of control over your career, lots of choices, and lots of time to correct your mistakes. Starting engineers can compete for a highly sought-after position at a big-name company or take a chance at a smaller firm. You can work with a huge team on a single feature that is the best in the world at what it does, or be a jack-of-all-trades developing creative solutions to unique problems for a vital product with a dozen customers.
Neither choice is right or wrong. Go for a job you think is out of your reach! It’s worth it to push yourself when you are starting out. There are lots of companies that have novice-friendly hiring policies such as internships or entry-level positions. Big companies often do better than mid-size companies in that area.
You will change jobs during your career, although hopefully you’ll remain at each position for about two years or so. It’s worthwhile to demonstrate patience and adaptability, and to give a company a chance to change.
On the other side of the coin, if you are fortunate enough to become a manager, you can keep your employees motivated by giving them a new internal opportunity every two years. Programmers enjoy fresh challenges; once you’ve mastered a problem domain, you need something new to tackle.
Most importantly, enjoy your career. Be curious; learn things; take on difficult projects; blog about your failures and give credit to others when you succeed. You can accomplish more than you think if you have a strong vision and bring everyone along with you!
This is the first article in our new blog series, Field Notes! Stay tuned for more advice from professional developers as they share advice and insight from their careers in tech.
Want to try out a career in tech for a day? Join us for an upcoming Code 101 workshop!
