Part I – The distraction
When I started at age of 13, 22 years ago, there were just a few accessible technologies to mess around with. Computers were not that accessible at that time and a household having a PC was kind of a luxury.
I remember that at that time the most used compilers/IDEs and programming languages for x86 DOS platforms were (Borland Turbo) C, (MS Quick) Basic and (Borland) Pascal; they were the ones I started with.
The internet was still forming and was not really mature, not how we know it today.
With the mass adoption of Win95 and later Win98 people become crazy about developing GUI applications. So much that each big company was eager to provide something new to the table. I even remember that VB had a timer object as a visual control that you can simply drag and drop to your app’s window and set its properties from the visual editor — no coding required. It was considered as a “crime” by the more skilled developers.
During the years, I’ve seen technologies come and go. Delphi, Visual Basic, MFC (Microsoft Foundation Class) just to name a few.
However, it was far from the boom of (so-called) web technologies we observe nowadays. There were just a few technologies provided by the big players and that was it. You pick one and learn it by heart, then use it until you get sick of it and then a little bit more (or at least until its entry point syntax got burned into your CRT display).
While it’s great to have options and alternatives, nowadays I see another, a little bit worrying trend.
Newbies tend to jump to every new technology that pops up (and they are popping up like mushrooms), thinking that knowing as many technologies as possible makes them better developers.
I strongly believe that this is a growth-devastating approach.
Don’t get me wrong — I think it’s fun and exciting to learn a new technology and you should stay up to date, but you should also not spread yourself too thin.
My advice to the newbies is that: Find the tech you like the most and stick to it as much as you can until you master it. Then focus on a specific area, not a technology. Stop chasing techologies and trends but rather specialize in a certain discipline. Technologies should be considered as tools, not recipes for quality or success.
And just to make things worse, understanding a certain technology deeply is simply not enough. Designing your software is as much, if not even more important. In order to write a good book, it’s not enough to simply know the language.
Software development is a complex enough discipline already. Keep yourself focused.
There is a reason that doctors learn general stuff for years and later specialize in certain area. It’s because their profession is extremely complex, even though they interact with just a singular subject like the single human anatomy.
I believe software engineering is as complex as any other discipline and it should be taken seriously.
And last but not least — self-discipline and working ethics.
You have to understand that in the end of the day it really doesn’t matter how good you are if you do not apply your skills in an effective and valuable manner.
Also if you are doing it for a living, you should not just be a good developer but also a good employee (or leader, depending on your role). This is however a topic for another article.
Working ethics however, are not limited to only job-related activities.
Ask yourself just two questions: are you happy when you buy a cheap crappy product? How do those who provide high-quality premium products achieve their results? I doubt it happens overnight with no effort and painfully long loop of iterations.
Working ethics are about working hard, non stop until you deeply understand the matter of the problem and you get it solved in the most elegant and simple way. The code is complete, not when there is nothing more to add to it, but when there is nothing else that you can remove from it. The boiling point of mastering something is when you become sick of it. That’s the point where you have nothing more to learn and you start inventing. Consider this as your compass through you journey of becoming a master in certain area.
So if you’re a newbie — keep your focus tight and at some point decide what would be your area of expertise. Don’t be a general purpose, mediocre developer. It’s a waste of time.
— Yuriy Georgiev (aka jeux), xLabs Advanced Research at VMware USA
Part II – The knowledge mess
Adding to what jeux was saying, tutorial hell is one hell of a drug. Youtube and a lot of other social media are filled to the brim with many flavours of ex-engineers’ manifestos; people that used to work in Google, Facebook, Amazon etc. If you derive your motivation from those kind of videos, in my opinion, you’re in for a bad time. There is no master key to success when jumping into the software field.
Are you chasing huge mystical piles of dollar bills at the monthly programmer cash giveaways? Would you ask a professional guitarist how can you pick up their lifelong skills in 24 easy steps? Or would you ask a lawyer if this “International law for dummies” helped them pass their bar examination? If your answer to those questions is no, you’re on the right track. Like any self-respecting craft, becoming a master at programming (a productive member of any team) takes a lot of hard work and don’t let any software guru tell you otherwise.
Are you prepared to sit for hours on end at your computer and slam your head into problems until you get better? These are the kind of questions you should ask yourself when you try to approach becoming a better software developer.
Repetition is the mother of all learning; this has never been more true in any case. My final advice to you is, stop looking for disgustingly simple applications to build with the new flavour of the month technology. Instead, build up from what you already know. Take some steps back, iterate and re-iterate until the tasks that seemed impossible and humongous become boring for you. Feel guilt when you copy-paste code you don’t understand, even if it is your own. Become a master of your own craft. It’s not about the destination, it’s about the journey.
— Alexander Nedelchev (aka frostwolf), Senior Software Engineer at Nokia Bell Labs