Friday, 8 February 2013

Developers, Share Your Technical Knowledge

When you think startup, you might get the picture of a bunch of developers writing code all day. While this can be true, the vast majority will incorporate some people that have absolutely no technical background.

I’m thinking about the ones working on marketing, sales, project management, product design, support, business development, graphic design and so on. All of them like the idea of working in a small and promising company, but they never learned anything about coding - and I’m not here to blame them.
No need to learn how to code

I’m personnaly not an advocate of the concept of getting everybody to code. Of course I love this field, but I wouldn’t say that it is a required skill to live a successful life, no matter how big technology is today.

However I’m all for giving people a basic overview of how everything works behind the scene of a successfull piece of software. Then, if the person wants to learn how to code for fun or to make a living out of it, great! But if not, I wouldn’t mind.

To each his own and bla bla bla.
Just get the big picture

As a developer, I’m always trying to give some technical references to my colleagues. Of course I won’t get into the details about how I optimized a complicated database query, but I might say that I got a page to load faster because I did something to the way the app talks to the database.

To sum it up:

Don’t say: “I refactored module X to speed up the GC in order to stop the memory leak occuring for the workers processing the queue Y.”

Say: “Our machines would use too much memory doing Y, so I had to improve how we would handle that.”

As time passes I might add some information and complexify my vocabulary as people get the idea. It’s all about introducing concepts step by step.

I’m absolutely not saying take them for idiots. They are not. They just do not have the same vocabulary and the same background as me. Imagine a marketing guy showing up and starting to talk about 4Ps without giving you any indication of what all those Ps are about.
What everyone should know

Spoilers: all that is written here is nothing more than my opinion.

I think that everyone in a startup working on a web product should know some things about how the software works. This is not the definitive ultimate most awesomest list, so feel free to add your points in the comments and I might update the article accordingly.

Here we go.

What code is. The fact that a bunch of text files can create a website, a game or whatever can be surprising for a lot of people.
What a browser is and understand that there are differences between browsers.
Recognize different kinds of problems. A complete crash is not as bad as a CSS alignment issue or a word change.
How to report a bug and understand that developers are not wizards that can guess the steps to reproduce it (if only).
What software regression is, or why sometimes a feature working yesterday is broken today.
What a server is.
Understand that something can be really complicated even if it seems simple. It’s rarely about just “adding a button”, there is way more to a feature than the UI.
What it means to deploy something in production. What is a migration. Why every once in a while you need to put the site down for maintenance.
What a URL is.

It’s not much, but knowing all this will help a lot communication between the development team and everyone else. To an extent it will also help the team be more efficient. Obviously it’s easier when everyone within a team can have a common vocabulary to talk about what occurs during development.

Going further, there are some subjects that can be very interesting if someone wanted to learn more. This can be particularly good for a person working on the product or selling it. Knowing more gives a better insight on what the app could do based on what is already there.

Databases. How things are stored, how the data can be used.
What are the possibilities and risks of using third party APIs.
Performances. What can make a site slow. Understand what asynchronous means.
Code reusability and its limit. Why it’s good to have a consistent product.

Bonus points to learn if you want to show off at dinner parties:

In most cases the cloud is really just a fancy way of talking about the internet.
Developers are just as bad as you at fixing printers.
Internet Explorer is terrible. Critize it and befriend developers.

Learning something different is also for developers

Working in a small structure like a startup is a lot of fun because you get to see what everybody is doing. All the people involved should take this opportunity to learn more.

So far I’ve talked a lot about non-technical people learning technical things, but a good idea for another blog post would be developers learning things non related to coding!

For instance knowing a bit about product design can help you catch wireframe mistakes before implementing them, or see an easy to create feature that could improve the application because you knew exactly what is possible with the current code base.

A front-end with an eye for graphic design could add a little polish to a website using the latest CSS3 techniques that the designer maybe didn’t know about.

No comments:

Post a Comment