It’s okay to be lazy! Laziness is your mind telling you that something might be overly complicated or difficult. This feeling can be taken advantage of to help you grow as a developer! Engineering problems often have infinite solutions, and in this talk, we will discuss how to follow your lazy instinct to find ones that are simpler and faster, and ironically allow you to become much more productive!
Jake Devine is a staff software engineer at Meetup. He describes himself:
“I am a lazy engineer. I’m willing to admit it. But what does it really mean to be lazy? You just really don’t want to do something. It sounds hard. There’s usually a reason why you don’t want to do it. If it was easy, maybe you wouldn’t feel that lazy about it. But you’d rather be doing something else.”
Laziness can be an important part of being a good engineer
If laziness is bad, then the opposite of laziness would have to be good. According to Jake, “If was building my dream team of engineers, I would want a team full of non-lazy engineers:
They’re solving every problem that they’re asked to solve every requirement. They’re finding a solution, working hard until every problem is solved, no matter what. They’re building complex systems that account for every possibility, every use case, every edge case, they’re solving it all. And they’re also working on 12 of these things at once, obviously, and actively memorising all the information that they need so that they can answer any question about any project or any technology or any topic on the fly. And it sounds great, but it also sounds pretty exhausting, right?”
There are pitfalls: “Maybe you solving and implementing every requirement that you’re asked to solve doesn’t work out in the sense that maybe your requirements change or your project changes, and you actually wasted a lot of work,and everything you build comes crumbling down. And why did you build all of that?”
People are engineers because they like solving complex problems. But Jake wants to ensure that energy expended is done in the right way.
Lazy evaluation for lazy engineers
Lazy evaluation is about delaying possibly indefinitely, the computation of values until they’re required, which saves wasteful work. The concept is there already. So how does Jake tap into his inner laziness to be more efficient in other ways?
Question requirements: When non- lazy engineers see a list of requirements, and they come up with a solution that fits every single one. It’s not doing people favours if you agree to do impossible things, and an impossible timeframe. So you’ll end up either under-delivering, which will disappoint the people around you. Because you promised to do something and then ended up doing less. Or you’ll be working yourself so hard that you’re basically working constantly, evenings, weekends, etc. which is bad for you, unfair to you.
Bridge the gap: Try to bridge the gap between yourself your team and product design and business people who you’re working with, try to understand their goals and then propose solutions that can accomplish those goals directly. And if you do everyone will be feeling pretty good.
Keep it simple:
Short term efficiency is really important, you want to be able to deliver things quickly and often and not always be focusing on the far future. As an engineer, there’s always something else to do. There’s always another way to make your class more generic another way and organise all your source directories, more edge cases to solve.
And usually don’t know where the future will take you.
Jake notes: “When you add complexity, your code also becomes much harder to reason about, you’re adding more complexity, it becomes harder to make changes. It’s harder to understand what it’s doing. And it takes a takes longer for other people, also To jump in and understand what your code is doing.”
He also notes that lazy engineers aren’t ignoring the future. “We’re actually trying to optimise for the future. Engineers, lazy engineers are lazy and don’t like having to do the same work twice. If you’re building simple components, it’ll be a lot easier to reuse them or build on top of them later on. Try to make as few decisions as possible, or at least delay them as long as you can. Don’t decide on anything that you don’t have to.”
Do fewer things at once
Our non-lazy engineer is always working on tonnes of different things. They’re taking on tonnes of different projects all at once. While multitasking, is a great skill to have, it doesn’t necessarily mean that you should always use it.
“In reality, we’re actually just switching back and forth between activities. This involves a lot of context switching overall. But every time we switch, we suddenly have to remember all of the contexts that’s related to our new activity, where we left off what the remaining open items are, etc.
Documentation is key to lazy engineering
When you need to remember something when you need to keep state, you can write it down. According to Jake, “documentation is inherently lazy, who wants to keep track of all of the information in your brain? That sounds like a lot of work. Once documentation is written, you don’t have to remember it anymore. Other people don’t have to record anymore either because it’s all there in your documentation and your notes.
If you’re about to switch to something else, just take 10 seconds and write down every, every single thing that is currently in your brain about the current state of what you’re thinking about. And then once it’s on the paper, you can forget about it, go move on to something else. And when you come back, just read it again. It’s not exactly the same as if you hadn’t switched focuses but I do this all the time and it saves me like 90% of the time it would have taken to like remember everything just b taking a little bit of time for myself, right before switching away.”
