Energy Driven Development

First published on

Over the years I've noticed a pattern when I'm developing software. When faced with a huge backlog of things to pick up, I tend to go with the tasks that give me the most energy. I've been calling this Energy Driven Development in my head. My team leads / PMs must have hated this back in the day, because I was often only giving a halfhearted attempt at the official sprint items, but I believe that it's often the right approach. When I wake up, and in the shower I'm already thinking about a problem and how to solve it, I should probably be working on that.

What personally gives me energy is if there are "deep problems" that require an elegant solution, so if you let me focus on those things, you get a well-organized codebase out of it, making all future development a lot easier.

I believe that if you have good engineers with a product mindset, they will have a well-developed intuition for what to work on. So if you're managing a backlog and are stuck in analysis paralysis, ask the engineers what gives them the most energy and let them work on that. It'll be great for motivation and ownership.

Comments

Post a Comment

Popular posts from this blog

The long long tail of AI applications

First published on
Image
Last year multiple companies asked me for advice. " We are evaluating this AI powered product, but do you think it makes sense at all? It seems a bit niche and we think ChatGPT might make this entire thing obsolete soon. " Long tail - credit to Wikipedia My answer so far has always been: "No, bare LLMs are not going to compete with this product." I think that people are failing to understand the distinction between different classes of AI companies. I see it like this: Foundational AI - creating models like GPT-4 (text), Sora (video) etc. Applied AI - using existing models to create smart applications. Note that there are also companies not focusing on AI - they will start lagging behind, let's forget about them ;) There are orders of magnitude  (!)   more companies that will deal with Applied AI than Foundational AI, and they will be very busy for decades to come. Here's why: To get the most out of LLMs, you have to ask the right questions. LLMs have acc...
Read more

"Security Is Our Top Priority" is BS

First published on
A couple of years ago I was asked to give a conference talk about software security. Well, actually I wasn't really asked, my company bought a sponsorship package with a speaker slot and I replied to the internal email asking for volunteers  🤣  Anyway, while preparing my talk, I realized a couple of important points about security that have not left my mind since: Security is limitless . You can always spend more effort to make things more secure. The same goes for quality, safety, employee happiness, etc. The needs of security are opposed to the needs of a convenient user experience . Improving one typically hurts the other. Now some organizations say "Security is our #1 priority". Really? You want to make something that has no limits your number one priority? I mean security is a good thing, but this seems a bit too simple? In fact, hollow marketing claims like that can make me a bit angry. In this post I'll help you understand what to make of statements like that...
Read more

The Future of Programming Systems - four thoughts

First published on
Image
Last week I gave a 20 minute mini talk at M&I Partners in Zeist about the Future of Programming Systems, and how the work of architects and engineering teams will grow closer together in the future. I'm completely obsessed by this topic so I'm excited! Here is that talk expressed in a blog post, slightly modified based on some feedback and new thoughts. Ok! Thank you for inviting me and sorry for not keeping to the original format as requested. I proposed this idea instead and it was accepted, so in part Matthijs (the organizer) is to blame and I hope it is OK with all of you as well ;) When cycling here, I realized I needed to make a last minute change and added "Systems" to the title. I believe that limiting ourselves to the activities of the programmer is too narrow, and we should have solutions that involve everyone who is in the lifecycle of software. So it's about the System  and that includes the designers, architects, users, database administrators, o...
Read more