making

Do all software engineers care about customer impact?

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.

Hackathons

I don't like Hackathons.

I remember when they went from fun to not-so-fun. I was part of the frontend modernisation project at Expedia. It was a long arduous project, filled with many many technical and people challenges. I loved it. Every day felt like a rush and we were doing something difficult that was going to have major impact. When the next company hackathon came along, I was more interested in carrying on with my regular work. What I was doing was more important and rewarding.

Hmm... does this mean people who love Hackathons just don't like what they are working on? Perhaps, they have a better idea to move the needle for the company? 🤔

From then on, Hackathons felt like a surface fix for a larger problem the organisation didn't know how to address.

Why do people love Hackathons?

Answers I've gotten over the years:

  • It's my idea
  • No processes or reporting
  • Something different
  • Low bureaucracy
  • Get to the end quickly
  • Opportunity to learn something new
  • Don't have to have a dozen meetings

In other words,

  • mastery
  • autonomy
  • purpose

People feel more driven.

This is no different when you work on home projects. Or when I write these posts. We have greater motivation.

I say, forego hackathons. Create outlets in every day operations to help people engage at the level of a hackathon.

  1. Make sure people understand why and are engaged in the problem being solved. It is more important that makers fall in love with the problem to be solved, more than the solution.
  2. Create opportunities to pitch and test new ideas out. According to Marty Sagan in the product management book "Inspired", most good ideas for the product come from the dev and UX teams. Provide a way to let those great ideas bubble up. Work on them.
  3. Generate a structure that is high in autonomy. Trust the people you hire. It is difficult to build great products in a top-down tyranny.

Don't encourage doing all-nighters though.

Recently, my good friend Jacquie sent me this YouTube by Corridor Crew. We were saying, they seem to have a lot of fun at work. Can yours been this cool?

Make every day work meaningful; make it fun.

Weekly Newsletter

I've been making plans to write about a specific topic on this blog for a while. I'm finally doing it. I'd like to write about my experience on...

..building a team of Makers.

If you'd like to keep up with the journey, hit subscribe on my newsletter. I'll send articles on the topic to your inbox.

Subscribe to Newsletter

Thank you :)

--

I'll keep it similar to sive.rs (thanks Luke for intro) or pragmatic engineer substack (thanks Shila for intro). Sample post here.

Getting a taste for making

Few years back, my brother and I decided to work on an iPhone app together. It was a little note taking app that I dreamt up to help me record lectures while taking notes. We gave it a terrible name… “notes + u”. App didn’t make it. It wasn’t a million dollar idea. We didn’t know much about making something great just yet.

But we had a lot of fun working on this app.

Every day was a new challenge. Everything had to be learned on the “job”. It was like being in The Matrix and learning kung fu. We learned about tooling, programming languages, design, marketing, copywriting… you name it. Everything was new. We read about the things we didn’t understand and tried it out.

I distinctly remember… I would spend hours on making some screen mocks. My brother would say he didn’t like it. I’d be pissed. Then I’ll try again, after maybe spending hours looking for inspiration on Dribble. It always got better with feedback. Likewise, I’d complain about how hard it was to manage CoreData threads… next day, there would be a better solution from him.

There was no mention of agile or process. We had day jobs so we didn’t waste time either. We just kept building something till we got there.

After the flop of the first app. We made many more apps. Each one better than the last. We made a little bit of money, which led to latest gadgets. But that didn’t matter as much as watching a live dashboard of people using our stuff. It was so exciting to see 50-60 people using the app at 8pm PST.

This feeling, it got really addictive. I don’t think it ever left me. To this day, I love making things. And I love to see people use the things I make.

I often wondered, can this not be “work”? Can’t I just make things that are useful to others in my day job and feel great? Work never felt that good though. Something about being in a corporate setting washed away the good vibes. Why was that? Can we not just focus on making?

My journey to this date has been to figure this out. Can I bring back that feeling of making to where I work? I think I can do it.

Our first app, notes + u