Let's take a look at some other things I wish I'd known when I started
You can find the first article in the series here.
Write your own side projects
Do you know what's one of the best ways of polishing your software writing skills?
Sitting down and writing your own software projects. Shocking, isn't it?
Programming is a practical skill, and in many ways, it's not that different from woodworking or playing an instrument. The more software you write, the better you become at it. Of course, you need to care about writing good quality code. In the same sense that practicing guitar with sloppy technique will create bad habits that will hinder your progress, poor programming practices will make you a bad programmer.
You don't need much knowledge to start writing your own programs. Just pick a topic you are interested in: music, movies, astronomy, or basically anything you feel any interest in. After selecting the topic, write a simple application around it, a command line app is more than enough.
Tackle a series of projects with increasing difficulty, it's important to work on things that push the boundaries of your current knowledge. Don't be afraid to look online or ask for help if you get stuck, programming is not pub quiz night and looking for solutions online is an important skill.
In no time, not only will your skills have grown considerably, but you will have a portfolio to show for future employers too. Go and write something, it doesn't really matter what it is, it just needs to be beyond your current skill level.
If you still don't know what to write, search for project ideas for beginner developers online. The internet is full of them.
Reading books is an important habit
It is said that software developers don't read enough books. We should.
Books are full of useful knowledge and important lessons from professionals who have been in the industry for decades. Most of the problems we find every day at work have tried and tested solutions documented in those books' pages.
It can be difficult to find good quality and up-to-date material, as most programming books are actually not that great due to the lax quality control most publishers have in place. Still, the amount of good books is by no means small, lots of great titles can be found in every area of our profession.
The most important thing is to read books on principles and concepts. Software ideas usually last much longer than specific technologies, and books written decades ago are still as relevant as they were on the day they were published.
Take as an example the Mythical Man-Month, a book about all the hardship we keep dealing with at work. Reading it is like reading one of those prophecies that became reality. Most of the same issues Fred Brooks describes in the book can be found in almost every workplace today. Why does every new generation of developers need to learn these lessons the hard way? well, maybe we should read more.
In this site, I have a reading list with my favorite software books. It's still far from complete, but it will continue to grow, feel free to go and check it anytime.
Avoid clever tricks like the plague
When I started programming, I loved seeing how much logic I could bundle into a single line of code. The result was obvious: my programs were a series of horrible and cryptic lines that even I could not understand.
Using clever tricks and compressing logic into a single line can be a lot of fun. It can even be a good way to solidify your understanding of how programming languages work.
The thing is, this approach is one of the worst things you can do when writing software. Your code will be read much more often than written, so you should strive to make it as readable as possible. In a couple of weeks, you and your colleagues will have forgotten what a particular line of code does. So make it easy to understand, it will save you lots of headaches.
No one ever opens a file, finds a convoluted line and thinks: 'oh well, this was written by a very smart person'. On the other hand, it's always a pleasure to read clear and obvious code, as it shows a lot of skill and professionalism.
Go for clarity, code is read much more often than written, so avoid at all cost those clever tricks. As a software author, your responsibility is to express a solution in the cleanest and most straightforward way possible.
Oh but I also knew all these things.
It's ok, maybe in the next article you'll find something you didn't know yet.
Thank you for reading, I hope you learned one or two new things or at least got something new to think about.
What to do next:
- Share this article with friends and colleagues. Thank you for helping me reach people who might find this information useful.
- Read the next article in the series.
- You can find helpful books to continue investing in your carrer in the recommended reading list.
- Send me an email with questions, comments or suggestions (it's in the About Me page). Come on, don't be shy!
