So what if you fail

When you start doing something, especially if that something is brand new to you, there is always a dark cloud of failing hovering over you. The probability that you will fail with almost everything you start doing, at least in the beginning, is pretty high. That fear of failing builds in us, it’s pretty irrational and keeps us back from achieving our full potential.
We don’t start projects because they will surely fail, we don’t give conference talks because we will mess it up and make a fool of ourselves, we don’t write blog posts because no one will read them, and the list keeps going on.
Imagine if all people who win the Olympics thought the same. I won’t run the marathon because someone will be faster than me. That is true in the beginning, but if you keep on puffing through, and learn from your failures, you will surely come out on top. I believe the feeling is linked to the Impostor Syndrome, and that the sense of failing if you try something new and don’t succeed will automatically expose you as a fraud, which you think you are.
Most people have stage fright, no one won their first marathon, and there is a microscopic chance that you will die because of that failure. You won’t die because you messed up (or didn’t) a conference talk, you won’t die if no one buys the product you made, and you surely won’t die if some troll comments on your blog post.
Don’t be afraid of failure, do your best to beat yourself, and try different things, maybe you are really good at giving conference talks, or maybe running, and you won’t even try because you will fail, and what? Is everybody going to laugh at you? So what, laugh with them, people will forget it pretty soon, and if you manage to own it and spin it off, there is nothing you can’t do.

Use Rack::Deflater to get faster first time loads of your app

Is your Ruby on Rails application slow for end users? Maybe you are sending a lot of data through the network. As we rarely test performance on our basic server to client setup, and I don’t mean the maxed out broadband speeds we like to have at our places of work, but regular DSL, or mobile internet user, with the minimal internet speed available.
We also have the false security while browser testing the application on the same machine we develop it on. And it’s really fast to fetch 10MB from localhost:3000 into the browser.
Do you think that pulling even a 1MB response is nice when the DSL speed is 2mbps and that means around 4 seconds to fetch it. Only your assets can grow to that size if you are not careful, and this is far from the response size of larger websites. For example, youtube.com has a payload of ~1.5MB (at least at the time of writing, my front page). And it takes around 4.55 seconds to render on my DSL which is around 10mbps. For a regular DSL user (~2mbps) the time it takes is 8 seconds, and the difference is, of course, the time it takes to receive the 1.5MB of data. For a mobile user it takes even longer because let’s be honest, no one can achieve those claimed 150mbps LTE speeds.
There is a very quick solution to reduce the payload of your Rails (and other Rack based apps) by including just one line of code in yours config/application.rb.

config.middleware.use Rack::Deflater

That will automatically deflate your server responses (which is a fancy word for compression that the browser knows how to uncompress), and you will be serving substantially smaller responses. Of course, your web server must be configured to enable compression, and there is a great guide for that here.

Just Fucking Ship

Two months ago I found out that Nathan Barry has a 24 hour product contest, in which he aimed to produce a real product, in the form of an email course, in 24 hours, from start to finish. It was really interesting following the process where he created a whole product, that earned a fair amount of money, in 24 hours, from scratch. Of course, it wasn’t from scratch, because he already has a couple of design products, but his process of making something in 24 hours seemed awesome.

One of the other people that I follow, and use their products, Amy Hoy, accepted the challenge and had her own product built in 24 hours. I bought both of the products, and although I’m not a designer, I’ll be using Nathan’s exercises for learning.
The thing I’m writing about here is Amy’s book, Just Fucking Ship, which is the sum of all her knowledge on shipping products fast. She takes us through a very convenient metaphor of creating a Thanksgiving dinner, planning for it ahead, and doing only the necessary things that you need to ship the product, or finish the dinner on time. Stripped to bare essentials, the final product (after 24 hours) didn’t have nice formatting, it wasn’t edited, and had no cover. But it was a product that had a price, and a place to buy it. It wasn’t perfect, but it was just enough. I’ve read the first version when it was out, and then the last (edited) one a few days ago. It’s a very short read and intended to be re-read every time you start creating something new. The updated version is much better, with nicer formatting, and although there is no kindle or epub format yet (I really love my kindle), the PDF is very readable on the kindle.
Amy’s language might scare off some of the purists, and it’s intended to. It’s really fun to read a book that is written just as someone would explain stuff to you in person, with real language, not overinflated purist nonsense. Go  buy the book, it’s only $19, and the price will probably increase in the future.

Specialist or Generalist

While reading a lot of stuff about freelancing, consulting and business in general, I stumble upon a lot of suggestions and advices to niche down, become a specialist in some weird and obscure skill, which will give you the recognition of being the go-to person for X. This thing surely works, and you shouldn’t throw the advice out the window, but there is also a different approach, what if someone is not satisfied with doing only one thing over and over again?
I had a pretty great and stable job before I joined the startup I’m working for now. I could have done that job (working primarily as an Oracle DB consultant, writing PL/SQL) for a long time. Maybe make that thing my career niche. But I chose something different, something more tangible, developing web applications. Although I did introduce Ruby on Rails at my previous company, and some of it stuck there, there was something else a startup gives you, something that everyone should experience in their career.
That thing is generalisation, because a startup doesn’t have 150 people working on a lot of things, but maybe 3-5 people, all working on the same system. That is the great opportunity to learn new things, and reuse some things you have learned before. Sure, you won’t be able to niche down and specialise in one particular subject, but you will learn a lot of new things just going along, and working with great people that have the same goal as you. You might start off as a senior developer, but over time you pick up DevOps, front-end skills, design skills, and even business and marketing skills. That is of course, if you choose to do that. You can always stick to doing your job if you see it as a job and never think about this again. But by the mere fact that YOU are reading this, you don’t qualify for the Dark Matter Developers group, and want to know and do more.
What I’m aiming at here is pretty simple, becoming a well rounded individual won’t make you a ninja X technology developer, it probably won’t give you much recognition in the community as being the go-to person for X, but it will make you a better person in the process. You will also realise that your development work isn’t the most crucial part of the product, but that there would be no product without all of the people, and their skills that go into creating it. Understanding how things are built, and what goes into them is a much better feeling than jamming down only on your main skill and monetising it, without a greater purpose in life.

Review: The Design of Everyday Things

I’ve recently read a great book, recommended by Merlin Rebrovic in one of his blog posts. I’ve always seen design as something abstract, something you need to be born to, and avoided it like the plague, not being born for it was the main excuse. However, after seeing that it is not really that hard and that you can learn design, I started to read a lot about it. I’m not an expert (yet), and I don’t see myself doing design professionally, at least not soon, but learning new and unexplored things brings me pleasure, and stepping out of your small box is great, because there is a whole world out there.

The Design of Everyday Things, a book by Don Norman, is a great intro into the world of design. And by that I mean industrial design. How to create products that people can use with ease and are nice to look at. I’ve read only the second edition of the book, which was updated to accompany the computerised, mobile world we live in now.
The book has plenty of examples of good and bad design choices, with the masochist teapot on the cover being one of the funniest. You will learn how design can help reduce the number of airplane accidents, and pretty much all accidents, where enough knowledge to operate something isn’t in the world, but required to be in the head. You can see a nice comparison of head vs. world knowledge here.
Badly designed products are all around us, and sometimes we don’t even notice them. It’s mainly because we have learned to cope with our stove where the burner to knob mapping isn’t that obvious. Maybe we have some exotic faucet in the bathroom, which is so clear to us, but guests tend to have issues operating a simple (or not so simple) faucet. Sometimes people who design these things are inexperienced, and wanting to make the prettiest looking faucet, not thinking of its usability, and putting too much knowledge in the head. Who want’s to read a 5 page manual just to be able to wash their hands? I know I don’t.
But nevertheless we buy those things, sometimes they are so stunning, and we just need to have them, not thinking about the usability. Sometimes we are on a budget, and we buy the things we can.
Sometimes the issue is in the production costs. It’s one thing to design a great product in a fancy 3D design tool, where only sky is the limit, and completely another to produce that thing, market it, and sell it at a price the market is willing to pay. Those design examples are limited to high-end products, where Apple comes to mind, or Bang & Olufsen, but their products aren’t really affordable to regular people.
Maybe if the people realised what a badly designed product is, they wouldn’t buy it, and the manufacturer would have to redesign it, because the competition has a product that is perfectly designed. But sadly we can’t hope for this to happen. Low budget, poorly designed products will always have a market, because people can’t spend enough for a quality product, and novelty items, made only to praise the visual design and not usability will always find their buyer among the people that need to have that fancy something, that no one can and will use for it’s intended purpose.
This book has opened my eyes to the crimes we developer often do against usability and design. It also pushed me in the direction of exploring user experience and design, in general. Hopefully, this will be a fun journey.