This is the continuation of the discoveries I’ve made since switching from coding as a hobby to a profession.
If you haven’t read the first post, you can find it here.
Text Editors vs IDEs
This could be an entire post by itself, hardcore VIM users vs. EMACS vs. fans of Visual Studio and JetBrain’s IDEs.
As it is your main work tool, choose wisely. Usually I’ve seen 2 types of developers – ones that take the stock settings and start working immediately, I happen to be of the second type – never-ending tinkering with the shortcuts, plugins, themes and whatnot. I, still, mistakenly believe that fine-tuning the development environment will save me time in the long run, but the time spent configuring rarely would be less than the overall saved time, unless you are a devOps configuring the entire development environment.
As the saying goes there is an XKCD for everything, the one apt for this case is:
Sometimes you just can’t use IDEs even if you are a fan due to the structure of system, running on different environments, using non-DPKG’d libraries, etc. If that’s the case, you will need to convert a text editor to an IDE. For me it’s Visual Studio Code, the progress on the editor has grown dramatically over the past months, it’s so configurable, fast enough for my needs and it’s multiple languages support is great, if you can live without auto-suggestions for the not as popular programming languages. I don’t condone IDEs, I still deeply believe that Visual Studio is great, especially if you C# for example. Clion for C++ and Linux development as well. It’s what works for you, I work in a team of 4 other people, none of us have identical setups – one is Sublime, one is Clion, one is GVIM, one is Eclipse and myself Visual Studio Code. What I’m trying to say is, the ideal setup for one person is not the ideal setup for you. Try an editor, IDE, discover what’s your best work instrument.
The compiler is your friend
Keeping up with the new technologies
You have to keep up with the latest technologies, you just don’t have a choice. I don’t know any other industry where in 5 years you’ll feel like an old man, there will be new tooling systems, frameworks. The simplest example I have is, in 2006 nobody could have predicted that mobile apps for iOS would be an entire industry force to be reckoned with today, as the iPhone, nor iOS existed at that point. Doing predicitions about future technologies is dangerous, rarely people get it right, so the best approach is to always be up to date. This doesn’t mean to jump on every buzzword technology for the sake of it, but to be wary to always look around to do things better in a modern way.
Software development is still in exponential growth, abstraction grows, entry barrier goes down, while this is still true, the stronger the above statement will stand.
I never commented my code before, as it was my stuff, assuming I’ll understand my thinking back then. I was very very wrong, when you work on a large product good luck recognizing your thinking as of a year ago, people’s coding mindset evolves as they learn new techniques, looking back at your own code from 5 years ago, you will most likely rewrite it entirely. I’m a strong defendent of simplicity of code, it’s a super difficult and yet fragile state of code to be achieved. I hate it when some developers say: “It was hard to write, should be hard to read”. This sounds to me – “I spent years inventing the wheel, you should go through all the same interations to reinvent it”. Nonsense.
One thing to be beware of is that comments sometimes lie, but code never does. Some commenting goes out of date, as some changes 1 line here, someone else changes 1 line there, next thing you know, the comment is not representative of what’s happening in that code section at all. Do not ever be over-reliant on comments, take them as hints, but nothing more. As a bonus, if you want to read some funny comments in code, head over to the infamous stackOverflow thread.
The necessary evil, still pains me sometimes when I have to re-write a large chunk, due to a difference in design. Nonetheless, code reviews have saved more production bugs than any other automated testing tool or syntax-checking IDE I’ve seen. Logic-based errors for now can only be caught properly by humans, might change in the future, but this is where we are now. One thing I’ve noticed is that usually you get your design influenced by the reviewer, which is why I think the code reviews should be left to the most senior programmers, as sometimes even though they cannot explain why this pattern is the right one, later in time they would turn out right. Also, if there is one person who would know what not to touch, it would be the person who has been there the longest and has already gone through the pain. They do come with their inefficiencies too, but the positivies far outweight the downsides, if you end up in a team that doesn’t do code reviews, start doing them.
Build time of compiled vs interpreted languages
Deadline Driven Development
That image speaks for itself, every person gets excited about a new project. They start building it beautifully and then deadlines pop up sooner than expected, bam, finish it up quickly and that pretty code suddenly became a bow of spaghetti. Pace yourself properly, I prefer to always have a margin for unforesable events, a new bugfix that will appear out of nowhere. I always give a slightly longer period that is actually meetable, rather than jumping hoops to get something half-baked out of the door on an early date. Different people cope with the just explained phenomenon differently. Find a rythm that’s reproducible and consistent, not just a one-off. Remember, when you are in that situation and say – “Next time it will be different.” Who are you kidding? Start doing something about this now. The habit of coping with crazy deadlines is built over time with experience, which is why I don’t have a panacea. Find your own solution.
As a closing statement for the two-post series, I’ll leave you with a quote a colleague of mine once said:
“Your job is to solve a problem, if you can solve it without writing a single line of code, you are the best developer ever.”
Never lose track of the actual goal, which is always to solve an existings problem, whatever tools make most sense to you and your team, they are the right ones.