I’ve been programming professionally for five years now. Since I’m likely to be in the field for many years to come, what I intend on writing here is a reference to see where I was at in terms of my approach.
Reduce Opportunities For Errors
Everything I do is focused around reducing the opportunity for error.
The first step is I pick a programming language that will require the least amount of code to achieve the task while satisfying other requirements around performance, longevity, and deployment. Sometimes that’s Python. Sometimes that’s C. The less code there is, the less opportunity there is the opportunity to introduce error.
I remove any repetition as to make the contents of my functions only be what makes them unique. Every repeating instance is an opportunity to forget applying a change I did to some other part. I also code in such a way to make some bugs appear at compile time rather than run-time. For instance, I’ll store strings as defines in C/C++ as to remove one type of repetition and make typos pop up as compile errors.
Employing practices like unit testing is another big way to reduce errors. It’ll catch some bugs that might otherwise fail to show up until a specific set of conditions occur in a running program, which can make it a pain to locate.
Write The Idealized Code
I structure code from the most abstract down. I specify what would be the function/method calls to make with the perfect library, one after the other, to solve a given problem. I then populate those functions after the fact, applying the same approach. Each invoked function/method is just a single-line return statement until properly populated. I refactor continuously.
I find that the top-down versus bottom-up approach leads to code that’s better structured and more legible.
Keep Code Legible
If there’s a Venn Diagram for ideas, this is one that is impacted by a slew of other practices.
I follow the conventions of the language. For C++, my functions follow the lowerCamelCase pattern. In Python and C it’s the underscore_name_pattern. If common practice dictates to use four space indentation, then that’s what I do. That consistency improves legibility for developers which reduces opportunity for error.
Likewise I always avoid those clever one liners. If it’s meaning is not immediately clear, I get rid of it. I want to remove as many barriers to understanding my code as possible. Leave cycle-level optimizations to the compiler. The losses that matter are usually several levels of abstraction up.
My lines of code never exceeds 80-120 characters, my functions rarely are more than a handful of lines, my files rarely exceed 200 lines. The more you have the more someone reading the code will have to track in their head, which makes the code less approachable. You want approachable. It also forces some level of modularization. The easier it is for someone else to pick up the code, the less likely they are to miss out the ways their changes could have unintended consequences.
I never comment out parts of code permanently as a way to disable it for potential future use. That’s what code revision is for. It just clutters up the code.
Only Code What’s Unique
It’s really fun and cool to solve problems on my own. Figuring out how to write an email client from the TCP level. Learning how encryption works. I’m all for that.
However, I avoid the Not Invented Here syndrome for production code. If there’s a library to do a given task, it’s probably better than what I could have put together on my own. I focus instead on writing the glue to interface with that library. I focus on the parts that make my software unique.
Sometimes it’s necessary to re-invent the wheel, but I only do so when there’s a demonstrable need.
Document The Code
I also document the code following whatever standard is set by the automatic document generator for that language. For Python that’s docstrings. For C/C++ I use JavaDoc for compatibility with Doxygen.
Comments are invaluable for maintainability. I hold the view that leaving it to the code is insufficient. Comments bridge the gap between how a computer thinks and how people think. The code explains how, the comments explain what.
I also automate as much of the documentation process as possible. I consider commit messages a type of documentation and use generators like Doxygen. For outward-facing code, if it’s not documented – it doesn’t exist.
Learn To Get Uncomfortable
Software development is unlike many fields in that there isn’t a relatively stable body of knowledge to work towards. Rather, that body of knowledge changes drastically every few years less you work as a programmer for NASA.
General skills around the process of software development are more static, but only just. Core knowledge around data structures has looked the same over the last thirty or forty years, but processes such as Agile and test-driven development are quite new.
So it becomes necessary to keep learning new things and to avoid staying comfortable with a body of knowledge.
I do this for two reasons. The first is that it really improves my workflow. All of these are born out of the lessons learned by other developers. Integrating those lessons saves me much time and effort, whether it be debuggers, revision control, unit testing, agile, etc. They were always prefaced with a learning curve that made me question their worth but it always proved invaluable.
The second reason has to do with my reality in which I’m seen as disposable. Every one of my friends in the private sector, with few exceptions, have recently been laid off. Some multiple times. My own company has reinforced the notion that I’ll be dropped the second it’s convenient to do so. In this environment then I have to be my own agent so that if I’m laid off tomorrow, I’ll be employable. I seek to hold myself up to the standards of the top developers I know.
Take Care Of Yourself First
The most important lesson of all though has less to do with code.
There’s only one person out there that can put your well-being first: you.
Don’t miss out on spending time with those that matter in your life (including yourself) because you were working nights and weekends. Take those impromptu days off for self-care. Spend time with your chosen family. Don’t look at your work emails after 5pm.
There are many companies and people within them that would rather you didn’t do this. Those people have different priorities. That’s okay. This is why you’re there.
There’ll always be people who make more than you. Maybe most people. But if you make a livable wage, have full-time work on regular hours, have your health, and a network of people that love you – then you’re pretty much golden. Those other people will have nicer things. Let it go.
At the end of the day, it’s the people that matter most.
And your time with them is the one thing you can’t get back from working evenings and weekends with a company.