Work smart, not hard

Sounds like the right thing to do but what exactly does it mean??

Some might? say it’s basically just about being smarter.? I don’t think so.? For me, working smart essentially means economizing your efforts.??

To do that you apply some smarts upfront to reduce the hard work on the backend.? That means; reading the docs, talking to SMEs, strategizing, diagramming, etc., then start working by writing the code.???

Hopefully by the time you're writing the code, it's become boring because all questions have been answered and? you’re just wiring the pieces together. ??Some of the questions? you answered are: which libraries to use, the general class structure and data shape, code flow, performance concerns, etc..? One of the more important questions that’s often overlooked by engineers is, is this really worth the effort or is this really the right thing to be doing. ? Asking those questions upfront may reveal inaccurate or wrong assumptions which means the hard work has just been reduced to no-work, saving time and money.??

While working smart can save money, it’s also cheaper in other respects.? For example, it’s cheaper to spend an hour reading the docs than it is to immediately start coding only to throw it out an hour later.? That’s the best case scenario. In the worst case, a couple weeks or more have passed before realizing there’s a critical flaw in the change and things have to be redone:

1. Maybe you chose a library that’s not well supported and thus not appropriate for production.??
2. Maybe you didn’t notice the CVE alert on the dependency.??
3. Your brute force approach is timing out.
4. Your recursion misses its base case in some circumstances.
5. Turns out it doesn’t actually solve the problem.

Case in point

I worked with an engineer who had been tasked with investigating a recurring bug that has been plaguing the company for years. ? She did 6 weeks of manual discovery work tracing out code paths? across several services owned by various teams.? Her conclusion was that another team needed to make a change which was still only a hack and not a permanent solution.? That was six weeks of hard work with nothing to show for it—no documentation, charts, graphs, or anything to share, just her word.? I was asked to take a look at it and came up with a solution in 6 hours.? I was able to hone in a solution so quickly because I invested some smarts upfront.? I pulled a name from the commit history which led me to an subject matter expert (SME) who had been around when the problematic code was originally written.? He explained the nature of the bug, why it’s intermittent, and what solutions seemed viable. The smart approach was to get a comprehensive understanding of the issue first.? From there I documented the problem and two possible solutions.? The smart approach was not just cheaper in terms of dev time, but it was cognitively cheaper too.? The docs also make it cheaper to address the bug in the future.

In conclusion

Working smart is not about being smarter or an IQ score, it’s about being informed to economize your efforts.? The more informed you are about an issue, the smarter you are on that issue and the better decisions you can make.? Better decisions lead to less work, and are cheaper all around in all the right ways.