How to sell a new technology to coworkers (and bosses, by proxy)

Have you been doing programming for a long time, in some old and boring, non-intuitive language or technology? Have you found that new technology everyone is talking about? Maybe it is Ember.js, maybe Angular, maybe even Ruby on Rails a couple of years ago. Do you burn from desire to use that new thing every day? Well, let me tell you from the start, it is not going to be easy.

I have had the same experience, with couple technologies in the past. Always looking for the next best thing. Whether it was MVC, Ruby on Rails, or git, as it was in my previous job. I failed the .net bit, and looking back, I’m not sad at all that it happened that way. Selling Ruby on Rails was different. Although I didn’t know about marketing and sales as much as I do today, I had a totally different approach, maybe not the best one, but the field to plant those seeds wasn’t very fertile.

The thing I changed was, showing the new technology to my coworkers, getting them to love Ruby, the same way I’ve fallen in love with it. Showing them the simplicity of creating a basic CRUD web application in Ruby on Rails. Making them the main advocates of the technology.

That is the basis of any product acceptance. Teach just one person, make them fall in love with the new thing. Talk about it, make a presentation, offer to teach anyone mildly interested in it. Because you have to get a following. And if you don’t get anyone to follow you, remember what happened with my try?

Selling to your manager, while going around your coworkers won’t work from the start. Your manager has their job, and while your job is creating beautiful and fast widgets, their is making sure you, and your team, produce enough widgets each day, to fulfil the set budget for that month. And they are really strict about allowing new technologies to come into play. Also, they have managers of their own, who they report to. Maybe there is some vendor lock, and you are unable to do it. Maybe the cost of training 150 people to use the new technology, just because one person says it’s cool, isn’t a really smart thing to do, especially if they appreciate their job.

Building a following is hard, and maybe the technology you found doesn’t have a big following in the world, or maybe it’s just too soon for it (Smalltalk anyone?). But if you are prepared to advocate it, and teach anyone who is mildly interested in learning it, create smart scripts with it, to help you with your daily job, putting it in contrast with the old and ugly technology you are using now, then you will succeed. Even if you don’t, you’ll have another tool under your belt, and you can always follow many of us who went freelance, to work with the technologies we like, and forget the ones we dislike.

Weekly review: Week ending October 19, 2014

I didn’t do much beside regular work this week. I underestimated the size of Benjamin Franklin: An American Life, so I’m still reading it, and it’s great. I knew almost nothing about the US in that era, so this is a very good history lesson, and learning about the life of such great man, which Benjamin Franklin surely was. Didn’t even manage to start the other books.

I wrote more than usual, and plan to hit at it a bit more from now on. Here are the posts I wrote and published this week:

There is one more pretty large feature scheduled to go out next week, so I’ll probably be under a heavy load too. That stuff gets planned in Wunderlist, which I really love using more and more, for private and business use.

Minimum viable feature

We have all heard about the Minimum viable product, and it is a great thing to strive for, if you are doing software development (or design). What in hell are the minimum viable features then? As the MVP(Minimum viable product) is defined as a product has only the bare minimum of features that allow it to be deployed, the same can be said for the features that the project is composed of. The guys from Basecamp once said something like this: Rather build half of a product, than a half-assed product.

While creating software, we often get carried away by shiny features we can add to the project, features that we may not need at the moment, or at all. Premature architecture optimisation is one of them, adding visual junk to html is another. Of course we all love shiny, scrolly, bumpy applications, but if you are creating a let’s say business application, you probably don’t need
that super fancy ajax loading widget that refreshes every 5 seconds. Or to have all of your 27 rows that get rendered in a select field properly cached 7 times in memcached, or redis. It just doesn’t matter at the moment.

What matters is that the product works according to the user story you have received. Same as the MVP on a bigger scale, when you get a new user story, ask yourself, what is the minimum possible set of code that I need to push this feature out. Thinking like this, you will create features in less time, which leaves plenty of time to write tests for your code (which I know all of you are already doing), and more time to spot out the flaws in your code, the user story, the UX, whatever.

Before you run out and create something barely usable, while finger pointing at me, please consider some base standards on how your application, and the features should look like. You can’t just put 5 inputs on a form, stick it on the page, write “Submit” on the submit button, and be done with it. You must make it look visually pleasing. It should also work fast enough that the end user can use it in a normal way, but not faster. While having super fast applications, where everything is cached, and vertically and horizontally scalable at the blink of an eye, if you are serving maximum of 42 users from your local government office, you could say you threw valuable time into something that you really don’t need.

I’ve comprised a list of questions I ask myself, which help in trimming down each feature to bare bones, while maximizing productivity:

  1. who will be using this? (how many people, what profile)
  2. what will be the impact of the feature to the whole system? (maybe some collision)
  3. can this process be reduced even more? (optimize work flow)
  4. should this feature be split in two or more features? (maybe it’s too elaborate)

Guiding myself with these, I’ve successfully produced feature after feature, all small and isolated, working their own things in harmony with the rest of the system. Now, to be honest, I’ve also written some bad code in the past, features that had nooks and crannies that I just had to put there. Or the story owner wanted them in, but that is a different story, about a really powerful and liberating word, NO.

Try to be concise, try to add only the things the feature needs to work. And hold yourself up to the project standard. If your project doesn’t have a standard, go write one. I could bet that no one will be mad at you if you create something good for the project. When creating the standard, remember why you are creating it, and keep it short and concise, with the minimum information needed to convey the information.

You are not just a (Insert language here) programmer

This is probably be one of those rant posts, so beware. I was listening to one
of the podcasts I try to regularly listen, and heard a good description of a
web developer. I like to call myself many names, and one of them is my
linkedin title Junior Shark Trainer, one of them is web developer, which
could be more precise (or broad) title than ruby on rails programmer.

If you do web development, or desktop application development (do those people
still exist, hello? :)), you are required to know a couple more things than
just wielding your programming language like a light saber, and slashing your
enemies with it. Here is an example, in the past 4 months, excluding the
text editors I work with, and explored, on the tasks involving web
I used:

  • bash (to write server creation and management scripts and various other
    little things)
  • sed (google it, it will blow your mind)
  • ruby (duh!)
  • javascript (and coffeescript)
  • html (plus erb, haml, handlebars)
  • css (sass, scss)
  • sql (yes it still exists, even if you are working with rails)
  • regular expressions
  • centos linux distribution

And probably a lot of other things that I can’t even remember but went into
web development process. OK, if your job title is Systems Programmer II
then you are probably only expected to know how to fire up your editor, and
crunch out code. I’m happy I never had to work at a company where someone else
had to set up my development environment for me each time I got a new
computer. I made a reference to being able to craft your own light saber in a
post called Importance of installing your own development machine
from more than two years ago, and I still hold that reference true. If you
consider yourself a developer, you should be able to set up the thing you are
going to develop. I’m not talking about knowing everything about anything. As
you don’t have to know how to set up reverse proxy and make your
infrastructure able to scale vertically and horizontally, on the click of a
button. But if you, let’s say, want to bootstrap your startup, all of those things can be
of use, before you can delegate them to employees.

Not my job syndrome also comes to mind, and I’ve had it before. Nowadays I
look at it differently. It’s not my job to design and improve existing UX
interfaces, but I’ve gotten interested in doing it at the moment. Or writing
copy, marketing, trying to increase conversion, or basic design, none of it
was my job a year ago. If I think about it, even web development was not my
job seven years ago. I was a back-end database (oracle) programmer, the SQL
skills are really useful even to this day.

So, embrace every learning opportunity, learn something from it, and do try
everything. Even the ugly marketing/business/sales side of things, which is
the hell on earth for an average developer, but if you are a freelancer, I
won’t break this to you gently. YOU ARE ALREADY RUNNING A BUSINESS, a
business of one that is, but still a business.

I might change my title to Thought Leader in training, whatever that might
be. I just hope I’ll never get to be Programmer Level III anywhere. Who would say,
it’s not that big of a rant after all.

Taking out the trash (So you can have new, shiny stuff)

Are you like me, and have a couple ideas (blog posts, products, applications)
lingering in your head? Are you also like me, and do nothing whatsoever about
them? Well, apparently there is an easy solution to that. Get them out of your head,
and sell them. What I mean by this, write the blog posts down, create your
product, or an application (MVP will suffice) and publish them, get rid of
them, and give them to the world.

I have listened to a Ruby Rogues episode on Creativity and
Technology a couple of days ago, and I caught one really interesting thing while
they spoke about writing in particular, but it can be applied to any idea you
have in your head. It’s really easy, the bare act of writing the thing you are
holding in your head, makes it go away. David Allen talks about the same thing
in Getting Things Done: The Art of Stress Free Productivity. And
the same thing applies when you clean up your home from the stuff that has been
there for much too long. You make room for new stuff. And if you are on a
constant improvement path, the new stuff will surely be better and shinier
than the stuff you threw out.

It’s a really simple process, and you will vastly improve your skills if you
start taking things out of your head and putting them into the world. Let’s
say, for example, that you have the coolest idea in your head. Not that you
think it’s the coolest, but something for the world to see. Let’s say that
your idea is an idea for the iPhone. And you tend to keep it to yourself,
while never acting on it. What will happen? Someone will come to the same
idea, maybe not as good, but will act on it, publish it, gather feedback,
improve on it and you lose. What if I told you that the first big idea you
have in your head isn’t really that good? And there are better ones to come.
But you have to clear out your mind so it can accept new things.

I’ve been on and off with my writing for a while, and the same thing happens
to me. I started writing things down, and better ideas came to mind. I even
made one of the applications I had in my head, and saw it as not really usable.
To the trash with it. Also, with a clear mind, you can afford to explore new
things, like Rhetoric, or design, or whatever interests you at the moment.
Most of us can be creative, if we choose to be. And you can’t write your first
book to be as good as one of Seth Godin’s books. But you
have to start writing, to get the junk out of your head, so you can come to
the really valuable stuff that lies underneath all of the garbage.

I’m going to steal a quote from the Ruby Rogues show to end
this post: Terry Pratchett once famously said, “There’s no such thing as
writer’s block, only lazy writers.”