Are You Hard to Convince?

When discussing a new technology, I’m rarely the first one to jump on the bandwagon. In fact, I’m usually the killjoy that ends up arguing against using a new library or a new language feature when the enthusiasm is high and everybody is eager to get started.

It’s not that I want to stay comfortable and never move forward. Rather, I need to be convinced that something is worth it instead of moving for the sake of it. New features and libraries can add complexity to something that’s already complex. That makes it harder for new people to join in (including you if you didn’t touch it for the last 6 months).

I’m all for new ideas that makes software easier to understand and that allows me to do my job better. Still, the argument about new technology is too focused on the shiny new technology itself, and not the problem it solves. A great idea is not enough; it has to work well in the real world.

To illustrate this, I choose a few templating engines at random on npm (not judging their quality; maybe they’re all great). Here is the kind of descriptions that will greet you:

Why should I choose one over the other, or use it to replace an existing tool?  A description like fast and powerful is not very helpful. It’s good to have, but who would pick a underpowered, slow engine?

Of course, if I’m looking specifically for an HTML template engines I can narrow it down a bit, but if I don’t have a strong preference one way or the other, what should I choose? There were surely a few problems or use cases that led to writing those engines instead of using an existing one, but I don’t have any way of knowing from looking at this.

At this point, I’m asking myself if the library will still exist in 5 years (without forcing me to rewrite everything every year) and if it’s well documented so I can get up to speed quickly, not if it implements a cool pattern in particular.

If I had to choose something for a project from that list, I would probably pick the ones that have the most promising documentation and a large following, and try them out for myself. Granted, it could still blow up later in production or when trying to implement a feature in particular since I’m only coding a prototype, but it’s better than nothing.

But after doing all this work, why would I switch to something new a few years down the line if the one I choose first still works well? I have to be really convinced that it can solve my problem better, and that is worth the cost of switching in improved productivity and ease of use. With the speed that the technology is moving I must be sure it’s worth it. I can’t afford to waste my time migrating to something that will make things worse.

Simple code is beautiful

Despite the large number of languages and tools that will get thrown at you if you mention web development (Ruby! React! Node.js! AngularJS! Gulp! Python!), the simplest web application you can create includes HTML, CSS and a bit of JavaScript for the interactivity. You don’t even need to setup a web server: just open it in your browser or host it with any cheap shared hosting and it just works.

Anyone can maintain this application with just a text editor, a web browser and some experimentation. It’s a great way to learn how the web works, and it is a good solution for a few pages showing static information or a little JavaScript calculator.

Unfortunately, it all goes downhill from there as soon as you need to save the state of the application or introduce some other form of server-side logic. Also, your application will soon turn into an unmanageable mess if you have to update many pages every time there is a small change.

Once you get started on this path and have chosen a web development stack, you’ll end up depending on many tools, technologies and frameworks for your developments process. In many cases, you HAVE to do this: most stacks don’t include everything, and you have to choose libraries according to the needs of your project. Unfortunately, every new bit that you add needs to be updated and can break on you. You need to find a balance between the time saved now by using a tool or automating a process, and the time waster further down the road if it breaks.

It’s easy to add dependencies, but you have to make sure it’s worth it for your project (see the left-pad debacle): a good dependency is something that doesn’t make sense to code yourself. You should never trust logic that is core to your application and that cannot easily be replaced to a third-party tool. That means that using a framework for two-way data binding or even just for handling AJAX calls is the proper thing to do, but a chat application that would outsource the chatting part is taking on a lot of risk.

The same goes for the code itself. When you’re thinking of trying out a fancy new language feature, you need to ask yourself if the immediate productivity gain is worth it. Will it make maintenance and readability harder for everyone working with the code (including you in 6 months)?

You don’t need to use each and every feature of a language. If you come up with a new way to do things at every possible occasion, it’s going to be very hard to introduce new people to your project. Using a small subset of the language makes it easier to understand what’s going on, even if it’s boring. You can experiment in your own learning projects, not in code meant for production.

Likewise, I like to keep my IDE as simple as possible, and work with a small number of tools. Many plugins are a great boost to productivity, but you don’t want to depend on all of them working perfectly to be able to do something. Also, if you deviate too much from the standard working environment for your technology or at your organization, it’s a lot harder to collaborate with other people. A simple environment meant you’re able to start working quickly, without spending hours reinstalling software to setup your environment.

If you’re just working on projects for a few months and handing them off to someone else to maintain, or if you’re just doing small projects to learn, it may not be as obvious, but those are all things that can come back and bite you. Your code will most likely be around for many years, and your tools must last that long or you’ll find yourself scrambling to find an alternative quickly.

Embrace the power of teaching to learn better

You’re learning a new programming paradigm, trying to understand functional programming and JavaScript. It’s going well and you’re completing tutorials and courses with ease but something is missing. Somehow, you’re having trouble making things stick in your mind and really using your new knowledge.

The most powerful way to master a new skill completely is to teach it to others. It’s not a technique to be taken lightly and is not easy to master, but it’ll supercharge your learning in a powerful way and help you become an expert in your subject of choice. Unfortunately, teaching takes a lot of time. You can’t share every last bit you learn. Rather, you should use this technique for subjects that are important to you or that you need to work on.

When you’re doing something, it’s a lot easier to fudge the bits that you’re not sure about. Indeed, everything will probably work fine even if there are a few parts that you completed by trial and error. When you’re teaching, you can’t skip steps: everything must be clearly laid out for the person learning. The process of teaching will help you how to structure your thinking and see where are the gaps in your knowledge so you can fix them.

You don’t need to know a lot to teach: you only need to be a step ahead of your students. Also, your English doesn’t need to be perfect, even if it’s not your first language. You’ll get better as you go along, and if your writing is clear and structured, the knowledge you’re sharing will still be useful to someone else. I’ve been blogging for over two years and my English has greatly improved if I dare saying so, but there is still a lot I can do to improve.

If you’re ready to jump in and teach what you know, how can you do it? There are many ways to teach that will give you the full benefits of this technique:

  • You can write blog posts, guides, and tutorials.
  • You can share your knowledge one to one at work or on open source projects.
  • You can record podcasts, screencasts and short videos.
  • You can give talks at your local user groups and at conferences.

Interacting with people is what makes teaching great. When you’re teaching, your students won’t have the same background as you: their questions will help refine and stretch your understanding of the subject. Everybody has their own strengths and their own way of approaching a problem, and you’ll learn from them as well.

So, go out and find people with whom you can share knowledge, volunteer to mentor people and don’t hoard all you’ve learned. You own knowledge will grow in leaps and bounds, and sharing knowledge is a joy in itself.