From Coder to Software Engineer [Part II]

From Coder to Software Engineer [Part II]

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:

XKCD Automation

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
As a starter developer, you always hate compiler errors, as they give you the sense that you don’t know what you are doing. This changed for me when I started troubleshooting JavaScript that just “always works”, but doesn’t behave as expected. You don’t get very useful errors or you have to debug a race condition. Then you hope for something to throw an error to know where to start looking to fix it. Over the past 5-10 years compilers have started to provide more user-friendly error messages. Simulatenously, the complexity of the languages has also grown – C++ 11 for example and right-value references for example. Standard library template errors still returns thousands of lines of errors, things can get better. The takeaway is that the compiler in reality will teach you the language faster, embrace it. Imagine it is like Clippy in Microsoft Office in 90s: 



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.
Front-end

Comments

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.

Code Reviews

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
Developers like C++ for many reasons, I do too, however the moment you end up in dependencies hell, the cost of building just grows ridiculously. After 3h trying to get a makefile with the right order of dependencies to link properly, you start to wonder if re-writing the entire thing in Python or JavaScript wouldn’t have taken less time. Interpreted languages have usually one massive feature I miss in C++ or I haven’t discovered it properly yet – package managers. Yes, there’s Conan, but it’s not as established, compared to what NPM and PIP are for JavaScript and Python. The saved time is incomparable to C++ in my eyes and adding manually Boost Library Headers, making sure everything is correctly set up for them and then for the rest of your project. The other thing, to test a simple statement is as easy as just running a Chrome web browser or just run python in a BASH shell, no need to setup compiler standards and 300 tails to the g++ compiler that are nothing short of pure magic for many. I have changed my opinion of interpreted languages dramatically, if you don’t have a large mission-critical project, you probably don’t need C++ even though it’s cool to do in C++.

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.
Happy coding!

Leave a Reply