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.

Figuring out how the CSS of a website works using Firebug – Screencast

The basis of using Cascading Style Sheets (CSS) to apply formatting to an HTML document is deceptively easy to understand, but hard to master. You define selectors that designate HTML elements, which contains formatting rules that apply to those elements and their children. If more than one rule applies to an element, they are applied using a priority order, from the more general to the more specific: that’s where the “cascading” part comes in.

It’s almost impossible to predict how a website will look by looking at the code. If you have to modify the CSS of an application you don’t know “just” to change a color or a font size using only your text editor, you’re out of luck. Figuring out the priority of each selector is complicated if you have many stylesheets that applies to a page, and you can easily miss a more general selector. You can’t just look at an element on the page and immediately deduce which CSS rules are affecting it, especially if there are many contradictory rules.

That’s where tools such as Firebug for Firefox or the Developer Tools in Chrome comes in. Among many other great features, they allow you to see which rules are affecting a particular element on the page, and to modify them on the fly.

Of course, it won’t modify your original CSS since it only changes the local copy in your browser, but you can quickly test what’s the impact on your page and then make the modifications. You can also use those tools to explore your favorite websites and see how they used CSS to format elements: it can be a great learning tool if you’re looking to grow your CSS knowledge.

Here is a screencast on how to use Firebug to figure out where the colors are defined on the Twitter website:

What you are is what you do

We define our work and our skills using various labels. Right now, I could say that I’m a software developer, a programmer, a product owner, a web developer, an Android developer and all those would be true. Still, those labels don’t tell you much about what I really do, or how much experience I have in each of those fields. Some people use labels that sounds way cooler such as ninja, samurai or hacker, but it doesn’t give then more skills.

Dreaming of adding an extra label to the list is an easy shortcut. I like to think that if I had all the time in the world, I would hack hardware and master all the latest buzzwords in web development, but that’s wishful thinking. I’m sure you also have a long list of things you wish you could do. Nobody can do it all: being an expert in many fields is demanding. Just maintaining your skills and keeping up to date takes work, not to mention learning new skills.

You are what you work on and keep practicing. Time is limited, so you can’t lie to yourself and pretend to be something you only do once or twice a year. Fortunately, this is great news if you want to earn a new label: you can do the work and it will come. You just need to do more of what you want to become, and less of what you don’t want to be.

It’s easier said than done, but if you’re aware of this you can use it to keep working toward what you want. You can drop being a Twitter or Instagram specialist and replace it with something more satisfying to you, like being a security specialist or an open source contributor.

This need real work and practice, and not just going through the motions. You must stretch the limits of your knowledge and try new things, not just read about it or listen to podcasts. Good practice is often frustrating and hurts a bit.

To make a skill part of your life, you don’t need to spend hours on it every week, but it needs to be a regular occurrence. Building a habit of doing a bit every day or every week is a perfect way to grow into a new skill. If you keep doing it, you’ll eventually become good.

This also means that some of your skills will decline with time as you use them less. Especially with technology, things evolve so fast that you won’t be up to date in everything that you ever did. You’re allowed to let some skills go, and it doesn’t mean that you can’t get them back as needed, since you won’t be starting from scratch. You can’t focus on everything at once, but all those previous experience will add to your overall knowledge, making you a better developer.