How you should (not) learn to code

Posted: March 26, 2017 in Programming

In order to achieve productivity and robustness of our applications, we are constantly introducing new coding practices, new tools, new frameworks. Consequently, with every new introduction of additional complexity we are permanently raising a bar for newcomers in programming business.

Trough time, process of learning is getting longer, required effort amount increases and we are failing to provide beginners with tools and/or methods for getting from point of not knowing anything to knowing something.

In that learning process – they are often left alone to choose any method to go trough that path by them selves. Very often, they choose wrong.

TLDR;

When I was starting with development (somewhat 16 years ago) there were no  such complex tools and technologies, there were no frameworks – or at least, it was not widespread  as it is now. You could get and do this job, very successfully, without knowledge of, per example, any programming framework. In general, if you could write down a meaningful “if-then-else” statement, you were good to go. Especially if you were a PHP developer, if you knew the meaning of PHP acronym – you were just fine, the rest could be handled along the way.

Nowdays, you ought to know at least one backend framework, some knowledge of Javascript is required as well as some popular JS libraries like jQuery, some CSS/LESS/SCSS is a plus, HTML of course and there is no reason to even mention SQL… But it do not stops there, you have to know to work at least in one testing framework, store your code in some VCS system (preferably git), manage your tasks in some software dedicated for that (like JIRA) and you should be familiar with deployment tools as well as with managing runtime environments (like Docker).

Beside tools, you should be familiar with good coding standards and practices, static code analysis, design patterns, etc…

Mentioned is just one small piece of requirements these days, and those are for entry level! And that list just getting bigger every day.

Learning by “writing the written” method – the wrong way

Lately, I have been involved in argues with few developers which tried to increase their level of understanding of few of the most complex concepts in OOP – MVC pattern and MVC frameworks and ORM and Active record pattern. Their approach was to write their own small frameworks/libraries, hopefully that in doing so they would understand the basic concepts and ideas behind them.

I have fought tooth and nails trying to discourage somebody in doing so, claiming that that is wrongly directed effort. Arguments were based on several paradigms and theories:

The very idea violates DRY (don’t repeat yourself) paradigm.

DRY paradigm (https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) is well known and already explained, so I will not go into further explanation, except, I would like to quote one quite important sentence from referred article:

Violations of DRY are typically referred to as WET solutions, which is commonly taken to stand for either “write everything twice”, “we enjoy typing” or “waste everyone’s time”

Libraries should be written (or at least designed) by experts in domain.

When someone writes a library, that means that he is fully familiar with a problem’s domain, its requirements, theoretical and academical basis and achievements in same, similar and related domains, common pitfalls, other approaches, good and bad practices in solving same and similar problems, in general everything about a problem that library ought to solve. Learners do not posses that knowledge – not even remotely, and therefore, most of the time they will do things in wrong way with extremely low (or none) gains in knowledge.

In development lingo – that learning method is anti-pattern.

In order for something to be declared as anti-pattern (https://en.wikipedia.org/wiki/Anti-pattern), at least two criteria has to be satisfied:

  1. Process (and/or structure) can appear as effective and appropriate response to a problem – typically has more bad consequences than good ones
  2. Another solution exists that is documented, repeatable and proven to be effective.

Learning by “doing it again” seams, at first glance, as a method that will help in understanding how things work and what are the motivations and benefits of doing them so. If you want to learn how to build a house – take bricks and put them together, right? However, the very fact that it is being redone by someone who lacks of expert knowledge about domain promises that a majority of effort will go wasted. Sure, from those fail attempts something will be learned along the way, but how efficient that acquirement of knowledge would be?

Take, per example, Rosetta Stone application for learning foreign languages – it mimics the learning process of baby/infant which learns words by connecting them with context and objects. It is true that you will learn, at least, a basics of language with Rosetta Stone. However, its methodology is major subject of critics. Simple put – baby/infant has more time to learn language (measured in years) and has slower pace and capacity of memorizing words and language rules in comparison to older adult.

Same goes to learning about MVC frameworks, ORM-s, you can learn about them by trying to write your own – but there are far more superior methods to achieve that result.

Learning through mentorship

Most preferable way and most productive way, there is no discussion there. You have expert with all the required knowledge and he will guide you trough everything, helping you with every obstacle. The fact that commercial companies are spending a tons of money for various lectures, trainings and mentorships for their employees is the very proof of how effective this method is.

That fact is major drawback of its appliance for individual learners – it is not easily affordable and experts are usually not available, either by their own work, either by the fact that knowledge transfer is hard job and they do not want to do it.

I mentored previously on voluntary basis and I do not believe that I would do that any time again in my life for any amount of money.

Conventional learning – reading/watching talks

It is free. There is a lot of things that you can find worth of reading/watching and a lot of things can be recommended to you for free to be read/watched. Method by itself is not sufficient, it has to be accompanied with some practical appliance and/or mentorship and/or guidance.

But let me hit you with hard facts. Without theoretical knowledge/background, any practical appliance, any mentorship, any type and method of learning, is just waste of time, yours and others willing to spend time with you in order to improve your skills. I have noticed a desire in every beginner/intermediate to skip that part and go strait away to practical appliance and practical knowledge, hoping that there is some shortcut that will help them graduate to “level pro” in shortest time possible with as less effort invested as possible.

There are no shortcuts. Everything that you miss will bite you in the a**, sooner or latter. It is very easy to spot when someone didn’t do his homework – didn’t read documentation carefully, or didn’t familiarize itsself with a topic/domain.

As a matter of fact – you should exploit this method as much as possible, you can not exaggerate with it. Read everything that you can put your hands on it, watch every video possible (of course, previously check credibility of author). And don’t put focus on one technology, one programming language – almost everything is portable, transferable and applicable among various technologies and programming language. Per example, in order to learn about implementation details about Symfony’s ACL security component (PHP framework) which was poorly written when it was published, I have read Spring’s ACL security component documentation (Java framework). In conclusion, read literally everything (of course, wrote by author/organization with credibility).

Join open source community and get involved actively

Lately, I have been promoting this idea a lot. Maybe because I personally believe that OS community have shaped me a lot. If anyone ever thought of me as a good/fine developer/architect it is because of certain people from OS world from which I have learned a lot (like Thibault Duplessis a.k.a ornicar, or Stéphane Erard a.k.a stephaneerard).

It is almost impossible to get best developer as mentor, fortunately, because of open source world and github (or other free source versioning systems) you can get second best thing: to learn from the best developers for free.

So, how you can do that?

Well, first thing – you can read their code and probe their minds, how do they think, how do they see problems, how they organize their code, files, classes and functions, what are their coding practices and habits, and so on. Personally, I have learned more by reading code rather then writing it.

Read issues, open ones as well as closed ones. You will find a lot of arguing there, but a lot of constructive arguing, and you can learn a lot from that. There is always a discussion about usability, coding practices, real problems, technologies… You can observe clash of opinions and see a lot of stated “pros” and “cons” and learn from them.

Read documentation and improve documentation. Open source libraries often do have poorly written documentation. Even the best ones do miss some chapters, or some better explanations of certain feature. Improve it, submit PR, help others by helping yourself.

Fix a bug, propose a feature. There is no better way to get practical knowledge then actually coding, so code something which benefits to all of us. There are a lot of bugs, much more than community can handle, so every effort is appreciated.

Write a test, improve test. Open source libraries suffers from low code coverage. And there is always a possibility to improve tests, to cover edge cases. You can easily spot if some line of code lacks of test, and tests are much easier to write then fix a bug.

Why you should invest your time in open source projects?

You will get an opportunity to work with best developers from the world, and you will be able to learn from them.

In order to submit a PR, you have to go trough library, documentation, code, everything related you can find – in order to understand it and be able to modify it in way that benefits to it.

You should be prepared to argue and to be rejected as well. In the beginning, that will happen, a lot! But that is a good thing, you shouldn’t be discouraged, on the contrarily – you should be more motivated.

And here is the well hidden fact: when you submit a PR, you get a free mentorship. Some hot-shot, well paid developer has to review your code, decline it and write you a reason for rejections. And that is pure gold – weather you believe it or not: in my career I have learned more from my rejected PRs then from accepted ones.

It is “quid pro quo” relation between you and a reviewer – if you are not good developer now, you will be better in 6 or 12 months from now, and every code reviewer in open source is aware of that. Not that they don’t want to be rude to you now, but they can not, they will need you – you are their free labour in the future and open source libraries are fuelled with free labour.

Eventually, your effort will pay off, you will return your debt to open source community, your patches, fixes and features will get merged, and you will feel as part of something more important and bigger then you (if you don’t believe that that is important, I recommend you to see this video: https://www.youtube.com/watch?v=rrkrvAUbU9Y).

With those contributions recorded and displayed on your github profile – you will get swamped with job offers and exciting opportunities.

It is “quid pro quo” relation – give in order to receive.

Work pro bono

I often hear a lot complaints from the beginners that they don’t have an opportunity to get practical knowledge and to get real-life problems to solve.

Nowadays, everything runs on information and I just refuse to accept that – there are a lot of real life problems to be solved, a lot more than developers in the market.

So, you need a real life problem to solve in order to get practical experience? Work pro bono! Find a NGO-s, find poorly founded government institutions and/or organizations, offer them your services. Ask your neighbour who has a small grocery store if he can provide you with sales data so you can write him a reporting tool, or business intelligence tool, or whatever creative application you can find.

If your motivation is truly to get practical experience – it is really hard to believe that you can not find a problem to solve.

********************

So, I beg you, if you are eager to learn and you have a spear time – please, don’t spend it writing something already written. There are far more superior methods which you can apply to acquire a knowledge.

There are no shortcuts, don’t look for them. We already did, we are telling you that from our experience, learn from our mistakes.

Your time and effort is precious and can benefit to us all, even if you are at very beginning of your career. We value it, why don’t you?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s