Real tools

So, I was discussing with @Clochix on the future of mobile/apps/the web, what are the costs for developers today to target as much platforms as possible, etc.
And then someone popped up in the discussion (and that’s cool, that’s the reason we’re having these discussions on Twitter), to comment on HTML5 tooling: (translation is mine)

devs prefer coding with real tools and users prefer real apps.

Clochix answered constructively asking for reference for this claim as well as definitions for “real tools” and “real apps” (“Facebook apps, Linkedin apps and the iOS ecosystem”). That intervention pissed me off (“real”) and since I’m a human being, I make mistakes so I answered unconstructively that as a real dev, I only work with real butterflies.

I feel this topic deserves a broader coverage, so I’d like to talk about my favorite tools to build web applications and software in general. So here is my list of real tools I use as a real developer in no particular order.


My brain

So I like this tool my brain is. It’s an amazing tool to think abstractly, model data, combine ideas. Our brains develop habits which make us faster and better at what we do over time usually. We have to be careful about forgetting our habits when they get in the way of moving forward, though.

With my brain, I can project myself in the future, imagine the maintanability problems in advance and lead to ways to avoid them in the present.

With my brain, I’m capable of cutting a problem into subproblems that can each be solved independently.

With my brain, I can bridge my understanding of a problem with the vocabulary the web platform provides to produce a solution to the problem.
My brain helps me remembering this vocabulary. Since my brain is very limited in capacity, I dump occasionally its content to MDN, so I can refer to it later. The MDN team is indeed making sure the website is up as much as possible.

This sounds like an obvious one, but I see too often devs rushing to their computers when a walk would probably be more effective.


Voice, email and patience

The vast majorit…. well… all the time, I build software for someone else’s need. I must translate their intent into code. My main task is to get their intent out of their brain. If I fail at this task, the code I write is most likely a waste of time.
Among other difficulties, most of the time, people don’t know what they want. Even if they do, they most often lack the proper vocabulary to express it. It’s a frustrating situation, but one we have to deal with just all the time.

It takes discussing, exchanging, expanding people’s vocabulary. It takes building something, gathering feedback, iterating. But not doing so results in endless cycles of disatisfaction about what’s being built… well… or you can screw your client over, but I always aim at success…

It’s a lot of work. Communication. Among other things, it involves cross-cultural concerns (not talking about cultures as in nationality, but culture in a broader sense), making sure the tone is right, seduction sometimes, manipulation in rarer occasions.
It helps a lot not wasting time, though.

I quite intentionally plan to master this art. Much more seriously than I plan to master the command line. We’re building software for people.


White board

Aw maaaan, this is my favorite actually. In my second year of software engineering school, I got involved in a project with a group of students and we had a room assigned for us. It had a whiteboard. Team design discussions in front of a whiteboard are just the best!
I miss whiteboards… I miss a team too, but that’s another topic, which leads me to…


A team

Not sure how ethical it is to consider a team a tool, but moving on…
Other people are amazing at seeing errors you make because they most often think from a different perspective. No later than a couple of weeks ago, I thought of a project and just discussing it over lunch with Thomas Parisot made me realize it was much more easier to do it as a Chrome extension than something with a server (Clochix would be proud). Bim! Saved hours messing around with server settings and going back and forth between browser APIs and Node APIs, just like that, over lunch.

A team is good for code review, for keeping things moving when you’re not at your best, for telling you to write test when you’d be lazy about it, for telling you how to promote your projects.

Teams are good.


Conclusive note

Tools like SDKs, frameworks, I can Google about them and given a few hours, I’ll know what to pick. In a few hours, I can find one excellent way to customize my CLI and I bet you the code to do it is even open source.

As far as I’m concerned, the tools I listed in this post are the ones that make a massive difference in my productivity. The rest of my tooling is a replaceable distraction. Coding itself sometimes feels like an annoying burden after the work of understanding the problem is done.

Please wake me up when the non-debates about Grunt vs Gulp or Ember vs Angular or MVC vs MV*MCC|PVM² are over. I’m making a nap so my brain rests😉

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