I’ve been working in the field of software for over 16 years now. I’ve worked for small companies, and I’ve worked for large companies. I have recommendations of books to read (though I really should start a database of books). I gave a small talk a couple of days ago, and I shared some points to start with. Here are the points that I advocated:
- Learn Version Control Software – This was something that was mentioned in college, but not really harped on. In the real software world, everything is done with version control. It allows you to track changes and see how the software is made. Learn it! Git is the most common, but there are plenty of alternatives.
- Read Books Often – It actually doesn’t have to be books, it can be blogs and various other things. Find stuff to read and stay up to date as best you can. Software is continually evolving. As people are writing software, they are evolving the practice of software engineering. New stuff will make your life better and easier.
- Understand Computer Architecture – At some point in your career, understanding how a computer works will help you. I have a story about a buffer overflow in Swift that wasn’t pushed back to ObjC that took me days to debug, and I was only able to solve by realizing the one device we were working on was a 32 bit device. Understanding architecture will help you with understanding performance trade-offs.
- Everything boils down to text – Everything is text, somehow. Packets going over the internet are really just text in disguise. Websites are mde in text. Everything is text. Even images are really bytes, which is text for computers. If you spend enough time, you can understand pretty much anything. It’s all a matter of time, usually not a technical limitation of understanding a problem.
- Have a website – This is advice from Being Geek from Michael Lopp. Create a website. It’s not super hard to do and will look good on your resume. It’s a great way to show potential employers what you have done.
- Do side projects – They don’t need to production level projects, but doing side projects is a great way to play with technology and learn about various different things. Notice a trend here, keep learning if you want to be successful.
- Learn as many langauges as possible – You don’t need to be an expert in all of them, but understanding the basics in many different langauges will help you. Being able to understand the advantages of one language over another is super helpful. Picking up a second langague can be hard, but if you have many languages under your belt, picking up a new one isn’t super hard.
- Learn people skills and start networking – Even though writing software is a skill, most projects are too complicated for any one person to do. You will need to work with others. Learning to do this effectively will help your career. It might also allow you to find different opportunites that might peak your interest.
- Learn the command line – I don’t care what system you are on, there is a command line under it. Learning the command line will help you be efficient and work on many different environments. Remember, everything is text.
- Keep notes and records – You will forget what you wrote in less than 3 months. Notes and records will be your best resource for remembering what you are thinking. Plus you remember more of what you write down. So write things down in a way you will be able to look back on them in the future.
- Become a power user of your software – You will spend your days using development software. Learn the keyboard shortcuts and all the tricks you can to be more effective in your software. It will help you save time, and that time will add up. It will allow you to spend more time thinking about the “what” of software.
- Learn about testing – saving one of the best for last. Testing can be your best friend. It can help you from breaking something you already had working and ensuring your objects behave the way you expect them to. I’ve worked for companies that have done too much testing (way too much UI testing can slow down development), but if you have a question, you probably don’t have enough.