I see many people learning to code struggle with understanding some concepts, which prove to be essential in daily work. When I run interviews I always talk about arrays (be prepared) and their methods. I do that as they open discussion to many possible situations and problems. They also allow debating complexity, optimisation, abstraction, mutation, and many many more. Without spending too much on introduction, I'd like to simply move to real-life examples. Yep! Real from code we recently wrote!

There are two things I'd like to mention in this blog post. First - how much fun is to play with various static page generators, including both Gatsby and Eleventy. Second - how senseless it may be. Let's start with the second.

In my experience as a developer, I made a few big mistakes. One of them was being late with taking building custom code instead of using ready, community driver frameworks. To be specific I missed the moment when with a seismic shit that autoloading and composer introduced to PHP frameworks like Symfony or Codeigniter allowed faster application scaffolding and testing. I tried to not repeat the mistake later and in the JavaScript world, I made custom code only once as after experience in Nokia Ovi team I failed to find good toolkit (dojo and YUI were there, but... were missing something). Once Angular appeared I used it, then NG2, then React and it stayed this way for a long time.

For a very long time, I kept using the same set of questions while performing interviews. Even though I created it with Angular in mind, most of them have proven universal. Asking about Arrays became my favourite (as in opens way to discuss so many interesting patterns like Observables) or CORS, which allows discussing how network requests work. Anyhow, recently I started to value more and more one I kept asking about setTimeout and setInterval.

I've just updated my blog by adding something that is essential for traditional blogging: chronological indexing.

One of the first obstacles for people just learning about software development is difficult to get real-life examples. Where it comes to learning types String, Number and Boolean are quite clear (tricky still). But when it comes to Object and an Array it's a different story. The concepts are too abstract for someone who never worked with code.

Don't get me wrong. To be a JavaScript developer you need to focus on understanding the language and mastering it. Then on specifics of the runtime ("place" where you code runs) environment, which most commonly will be either browser or node (which in many cases will mean "backend").

When we started the migration to React we faced an interesting problem. Most of the resources explained data structures in React on very simple examples. Our data model was far more complex. Also, we had to combine React with other stacks, like GridLayout (based on jQuery) and leave the ability to shift to any other codebase in the future.

TLDR Documenting massive redux models with asynchronous actions can be simplified by using old good Graphviz and few comments in the code.

Sometimes it's worth to share an opinion. But as I decided to go more with the facts I'm going to base it on some recent experiences.

I will risk a thesis to start with - you can’t judge seniority of the JavaScript developer by experience counted in years.

TLDR If you have no time for TDD, you should at least use types.

Times when many recruiters mistaken JavaScript for Java are long passed (except some rare awkward situations). Anyhow there is still very low understanding of specific technologies on JavaScript scene. It's nothing surprising as the market is very fast, tools change and new methods emerge almost every day.

I do enjoy good practices in coding. I love the direction that many environments take to organise code and make it maintainable. But very often we think about our code and forget about whole world around it.

1. First of all, you can get criticised. You may learn something from it, so you can improve. It's dangerous.
2. Code shows your skills. They improve over time. Future employer can see you grow. That can end up with too big salaries.
3. By resolving your problem you can become contributor of huge project. Like posting pull request to some framework. Then recruiter would think, you are a super star... you don't want that.
4. Your code won't be hidden, ever... Imagine you do something cool, even for yourself. Great new business idea. And then you create snippet that is cool to. Only think is that this snippet has own value even outside the project. On the other hand it isn't something that affect value of the project. Say you build website for estate agencies and you have built nice CSS effect making buttons blink like Kardashians. If you don't publish that snippet as open source it will be forever safe. If you sale your project no one will use that snippet except new owners. If you publish it, you will keep all rights and it will be used by others... what a lose.
5. Your code won't produce any direct money. No. Worse. You can build business model on top of it that you may not like. Like Symfony or MEAN.io. Making money on service, training and support. Do you don't want that mess and scaling business. You just want to code for food...

In the end...

Advertisements for a long time isn't simple topic anymore. It's not just putting one square on your page and hoping for some money to come back. You have to consider multiple factors like:

Have you ever asked your developers to do some project for you? You spent vast amount of time on describing your goals, making mockups, explaining needs. Then you get something that looks ok, but once you start to use it it falls apart. You click something and result is not as expected. You ask about it and you get an answer „it was not defined“ or „it conflicts with other thing“. You keep asking „why you haven’t said it back then?“. Answer is „well, we didn’t know you will go that way“ and again „you haven’t told us about it“. Constant blaming starts to make your furious, team furious and your project goes nowhere. Well. In fact I am not going to make you help any better. Your developers were likely right. Good for you, is that they are also one to blame.

"laws were most numerous when the commonwealth was most corrupt" Tacitus

… read more…