software

Do all software engineers care about customer impact?

in , ,

I got into a fun chat with my friends about unengaged people at work. Do software engineers care about salary, solving a problem technically (discovery), shipping, or does that work has to have impact in someone else’s life? Of course, different people find joy in many points within this spectrum of outcomes.

Interesting question surfaced: is it that some people don’t find joy in having impact in others or have they just not had the opportunity to make that deep connection to their work? I mean, nothing wrong with just finding joy in solving problems, right?

I referenced 2 stories from my past.

I used to go to church multiple times a week and be involved in many religious activities. I was happy and I never really thought past the bubble I was in. Then my circumstances changed with where I lived, my closest friends’ life circumstances etc. It led to me inspecting the bigger “why’s” of life. As a result, I incrementally focused my energies elsewhere and dropped out of church.

Second story was just me as a software engineer. I loved experimenting with new technologies and making fun little UI apps. As a teenager, I had an obsession with how traffic lights worked. I found it really fun to code road junction in Java Swing UI. It was a fun way to learn Java but also… just liked figuring out how things worked.

Then I made a jump to building some iOS apps with my brother. I’ve written about this before. Watching us have direct impact in someone else’s day was just incredible. I was working for Vigil Systems at the time where we guaranteed 15% reduction in public transport accidents (sketchy memory on this metric). These things mattered to people. The direct interaction and knowing how my work helped people was a wonderful feeling.

After that, I always wanted something more. It wasn’t just enough to write good code or ship things quickly. I wanted to know my code made a difference and it helped people to make time or be better off in some way.

So, is it that some don’t get to experience this moment in time that helps them break out and think beyond their Jira cards? If you are starting off in a big technology company, it is really difficult to have this direct connection to customers to begin with. Most developers I work wth never had to explain to a customer how to find a feature in the interface they coded in. By the way, it is extremely frustrating to see people struggle with what you’ve built.

This image came to mind… this is Maslow’s hierarchy of needs:

Are we just thinking about people in different stages of this pyramid? Does everyone have the opportunity to attain self-actualisation? Does self-actualisation mean having direct impact in others?

I think it is pretty important to generate that connection at some point. But we should remember that sometimes, we find meaning in having impact in others’ lives… and sometimes, discovering is just as important. The very act of making and having fun can lead to things. We don’t have a clear purpose in life. So these competing forces — this chaos — keeps us vibrant and moving forward.

Whatever it is for you, I am hoping you find engagement and joy at work. It helped you stay motivated. If your current work doesn’t give you that, find something that does.

Related article to read: How to burnout a software engineer, in 3 easy steps.

Big redesign in the sky

in

This is perhaps one of the greatest articles every written on software rewrites. Every single developer should read and understand what it is trying to say.

...but the reality of green field projects is that they create the illusion that your messes don’t matter. Your messes do matter. Every single one of your messes matters. And if you don’t clean them up from the very start, you are going to wind up with a horrible messy legacy wad in short order.

How true. Few years back, I went through most of what is written in the article. I watched two systems, built to replace the same system before it, one after another. We fixed some messes but didn't quite understand what we were trying to overcome. Each new system got out of date and messy faster than the previous one!

This was also the reason for me hiring the architect for my new home. She walked around the old place and asked us about our messes, habits and workflows:

Why do you have a chair here? Is this where your mail pile up? Why do you take work calls from the sunroom?

Nowadays, whenever I hear about the need for a rewrite, I dig into understand issues in-depth. They often surface smaller pieces to fix.

Why is it hard to deploy? Let's run through a recent feature, why did it take so long?

Couple of other questions I ask:

Where do the rubbish pile up in the system? (example: are all the AB tests wired in your REST API and it is a monster...) What system do you have in place to collect the rubbish periodically?

Lastly, my colleague @Anuraag used to say:

Is your rewrite trying for a revolution or evolution? Definitely don't attempt a rewrite if you are looking for an evolutionary change.

Keep this in your bookmarks. Read it often. Share it with everyone. Thanks @JoeS for sending this to me few years back.

Do "basics" well

in , ,

High performing teams are about interperson chemistry that is built on a foundation of the “basics”.

Take sports for example.

Learning to play a sport require you to learn the rules and develop basic skills to play. For soccer, it would be passing, tackling, lobbing and shooting.

When you join a team, there’s drills, runs and short set plays. These are repeated over and over during practice. During a full game, these disconnected pieces mix together to form fluid play. Play together with your team for long enough and magic starts to happen — team members anticipate each others moves to outplay opposition.

Drills, runs and set plays allow you to improve and build on the basic skills: passing, tackling, lobbing and shooting. They improve player fitness and execution during gameplay.

The act of continually working on the basics seem to lead to continued advancement. This is an interesting idea as it would be easy to assume the opposite — to advance further, one has to work on increasingly complex drills. I think it comes down to the fact that most complex things are built up from very basic elements. The more confident and efficient we are with basics, the more opportunity we have to put them together to do complex things.

Therefore, I believe, basics and chemistry form important attributes for any team.

Chemistry can be a complex thing to establish, with time, environment and the individuals themselves. It’s a whole other discussion.

It is easy to establish basics when talking about soccer. What are the basics outside the context of sports? I’ve been trying to figure out what forms the basics for a software engineering team. Is it design patterns or code reviews? Is it practicing readiness to production issues? Or perhaps, it is our ability to document and capture tasks in Trello? These seem to be the essential building blocks in a life of an engineer; solving problems by applying technical concepts into code, that outputs a product to deliver value.

Software is more than just code. At the heart of it, it is empathy and collaboration. It is a bunch of people, observing and acknowledging pain felt by themselves or others, deciding to take upon themselves to resolve that pain. Solutions doesn’t just come from one individual. It is the work of many, fusing their minds, disciplines and skills together to make something truly valuable. For me, the basics for a team are contained in these core values.

Basics has to be more around the idea of problem solving. That is all we do as a team, every day. Even our individual disciplines themselves are various ways dimensions of problem solving — research, design, engineering, analysis etc.

This idea became clearer when I recently read the book “The Culture Code” by Daniel Coyle. The book investigates the elements of highly successful groups. There is a great case study around Danny Meyer’s wildly successful restaurants. In a restaurant, how should one go about preparing staff for both conveying the right feel to customers and be able to react to new and complex issues that come up? It is impossible to cover all the bases and situations.

Danny uses the idea of “heuristics”. He captures the behaviours and his ideology in short, catchy phrases that are used in high frequency. Staff learn to apply these heuristics in every day complex situations, leading to very delightful customer experiences. Applying these heuristics seem to be the basics Danny get his staff to focus on.

These “heuristics” aren’t the same as rules. They are shortcuts for understanding and applying “guiding principles”. They convey a behaviour that is core to situations that arise in a restaurant environment. They allow staff to be thoughtful and creative, while being aligned towards providing customers with a unique, delightful experience.

Heuristics based in problem solving… these can be our basics.

Here are some ideas for heuristics I’ve been collecting with the help of others:

  • Just start.
  • Try and try again.
  • Optimise for fast recovery.
  • Act like it is your company.
  • Coaching over management.
  • Challenge assumptions.
  • Understanding the problem is half the solution.
  • Ask why.

“Just start” — we can apply this heuristic over and over in many occasions, whether people are stuck on a decision or unsure of estimates. It embraces the culture of a “maker” in having a bias for action.

Whenever someone asks me why we allowed a bug to go to production, I like to say: “Making mistakes is part of the job. We’d be better off if our system was optimised for fast recovery instead.”

We do workshops to help everyone understand how to write a good problem statement. Because “understanding the problem is half the solution.”

I believe that practicing these basics of problem solving can lead to powerful teams. They can provide the fundamentals that enable magic to take place.

Keep practising. Keep doing basics well.

Making Safari Suggested Passwords Sync with Chrome

in

With the latest OS X Mavericks, Safari browser introduced a very convenient way of generating safe, random passwords when you sign up for a new account with any website. I've started using this feature extensively. It syncs across my iPhone + iPad beautifully as well. Only problem is Chrome...

Right now, I have a manual solution. Turned out to be a little easier than I thought:

  • If you open up the Keychain app on the Mac, You should see two items of interest: "login" and "iCloud". Chrome picks up passwords from Login.
  • Go to iCloud section, arrange by modified date.
  • Select all the recent signups and do a CMD + C (copy).
  • Navigate to login section and do a CMD + V (paste). It's prompt you for your Mac password, go ahead and enter that.
  • Chrome should now pick up the passwords automatically, sync across to all your Chrome browsers from now on.

Wisdom on Pricing Software

in ,

Recently ​I came across this excellent blog post, "Million Dollar Art", by Nate Otto on the Signal vs Noise blog. I started thinking, how relevant is it for software? Can you simply put a million, or even 30 grand price tag on software?

​We first discussed it at work and there was the rational opinion that IT products help save time and effort. If a single person's job can entirely by done by a piece of software, then it should worth that person's salary. This makes valuing software quite easy!

Why think when you can Google. I came across this wonderful article at Smashing Magazine: You're pricing it wrong: software pricing demystified. It talks about the rational price vs. the perceived value of a product. Seems like branding, good marketing, superior design, support, average price for competing products and a number of other factors can increase or decrease the perceived value of a software. Read the whole article and some of the related links to get a better idea. Highly recommended!

​When it comes to apps, the perceived value always seems to be much smaller than the app is really worth. 99 cents is very popular on the App Store. However, I think it will be wise not to go with the flow and really think about your audience and what they'll be willing to pay. Better yet, try to bend your ideas to fit to an audience which has more money to spend (Business Store for example...). Most importantly, be flexible. Start with a slightly higher price and be wiling to experiment with the price. You can never know for sure. Don't give away anything for free.

​There's one caveat: iTunes rankings! Giving an app away for free might mean that you get more downloads on launch day, provided you run a great marketing campaign. Then, things become real tricky moving forward.

We're about to do some testing with pricing with the launch of tvQ 2.0. Will write my findings post launch.