I’ve been a Software Engineer and web developer for over a decade now. Companies such as Dell, AOL, and eBay have used my software to create unforgettable experiences for millions of people around the world. I’ve built, run, and sold software companies that have generated hundreds of thousands in revenue and gained millions of supporters. Here are some important lessons I’ve learned in that time (in no particular order):
A programming language is a tool you use to do a job. The job itself is problem-solving.
Deprecate yourself. Don’t be the go-to person for the code. Optimize it for people to find their way to fixing bugs and adding features themselves. That way, when you leave the whole thing doesn’t fall into disrepair.
Code has a shelf-life. It doesn’t last forever. Sometimes it dies before seeing the light of production. Don’t attach your (or anyone else’s) identity to the code. Realize that people are separate from the artifacts they produce.
Don’t just write good code, write good errors too. Good errors answer three important questions:
Why it happened
How it was detected
What can be done to resolve it
Don’t overengineer. Don’t do speculative programming. Don’t solve a problem that doesn’t exist. The best code is no code.
Remember there are huge fields of knowledge that you know nothing about, even within your career domain. That’s ok. Ditch your imposter syndrome and instead delight in learning from and teaching others.
The best software engineers think like designers. Great engineers consider who will be using it, why it will be used, how it will be used, and what is important to those users. It’s all about the users.
Don’t bet against old technologies that have stuck around. They’ll be boring but will get the job done. There’s a reason they have survived the rapid changes that occur constantly in the tech world.
Software engineers should write regularly. Writing not only helps you think about your problems but it helps you communicate those more effectively with your team and your future self.
Build small and iterate. Fight the temptation to build bigger at first. You learn so much while doing the former that it will always beat the latter.