article

productivity

August 1, 2019

5 lessons software engineers can learn from “The Effective Engineer”

Editors Note: Being a productive software engineer has nothing to do with your technical skills or background. It's a mindset, a different look at the way you use your time. This is especially crucial early in your career. In today's post, Former premed - now senior software engineer Lily Chen shares the lessons she learned from the book "The effective engineer" by Edmond Lau.

One of the opening lines of The Effective Engineer is

“80% of the impact comes from 20% of the work.”

One of the most important skills an engineer can learn is thus identifying high leverage activities.

Leverage is defined as impact produced divided by time invested.

This principle really resonated with me.

As an engineer early in my journey, I often find myself blindly going through Pivotal tickets without asking whether the time I spent is worth the value added.

Not all work is created equal. However, telling someone to “find and prioritize high value things first” is easy; how do you actually identify them?

As I am still early in my career, I clearly don’t have all the answers to this question. I believe being able to identify high leverage activities is a skill that comes with learning and experience. Nevertheless, here is a list of pointers from The Effective Engineer I follow that has helped me become more effective at work.

I. Engage with product decision makers

As an engineer, it’s so easy to fall into the trap of the before really thinking about the and the

What I mean by this is we (at least I) tend to jump into implementation straight away before really understanding the problem at hand.

Few months ago my boyfriend and I decided to start a side project together. During our first whiteboard prototyping/product brainstorm session, I’d always fall into the pattern of jumping straight away into all the features we should build.

He’d stop me and ask:

“Why should we build this? What problem is that going to solve? What value is that going to add?”

And I’d have no clear answer.

In order to get a good sense of the potential impact of your work, you have to understand the and the behind the feature.

Product meetings are when the whats and the whys are addressed. I make it my goal to attend design reviews or product brainstorm sessions at least once a month.

With a clear context of what/why, it’ll be much easier to identify the significance of a particular feature and the potential value added.

II. Read books in “adjacent disciplines”

One of the advice that the author gave for growing as an engineer is to become more well-rounded and learn things in adjacent disciplines. E.g. If you’re an user acquisition engineer, read a book on marketing or behavioral psychology.

I recently read Positioning: The Battle for Your Mind. Positioning is a book about how to do marketing right in the current age of digital over-bombardment. Though not immediately applicable to my day-to-day work, it was nevertheless fascinating to learn basic product marketing strategies I have never had any idea about.

Reading books will help you understand product decisions better and make attending product meetings much more meaningful.

Reading books will also help you become more well-rounded, which is important too if you want to start your own company someday.

III. Ask your peers for their feedback and help

I know imposter syndrome is common in this industry. I too have experienced the feeling of “not being smart enough” or “talented enough.”

Adopting the right mindset is critical when it comes to growing as a software engineer. I have found that by not being afraid to ask for help has increased my productivity because my teammates often point me in the right direction.

Asking for feedback early is also good.

Whenever I work on a big feature solo, I always get validation to my approach from other engineers early.

This accomplishes two things:

I know I’m not spending hours on a strategy that’s ultimately flawed or unoptimized, only to have someone else suggest a cleaner approach during code review. Additionally, by starting the discussion early, I build a more comprehensive list of pros and cons of various approaches. As I carry out the project, I have time to reinforce my understanding of these pros and cons.

IV. Pick projects that optimize for learning

Along the lines of growth mindset, when possible, I choose projects that I don’t necessarily know how to do from the get-go.

Needless to say the tickets looked intimidating at first. However, after working through them, I became more confident in my ability to learn and I gained greater courage to take on bigger challenges.

As Edmond Lau quoted in his book:

“Learning follows an exponential growth curve. Knowledge gives you a foundation, enabling you to gain more knowledge even faster.”

V. Take a Machine Learning course (or a few)

Technically, Machine Learning specifically wasn’t in the book. However, it follows the principle of optimizing for learning and investing in skills that are in high demand.

I singled out Machine Learning because I personally find it extremely intimidating. Yet at the same time, I’m now convinced it’s crucial to be familiar with some basic concepts should I choose to stay in the tech industry.

This is a text conversation I had with my boyfriend about a month ago:

Him: “You should reconsider your decision not to be interested in machine learning.”

Me: “What made you say that all of a sudden?”

Him: “Part of my job is to know where the world is moving to. Every company now wants to be a software company, and every software company wants to be an AI company.”

Last week, as I was reading the July/August edition of the MIT Technology Review, I came across this exact quotation:

https://www.technologyreview.com/s/607831/nvidia-ceo-software-is-eating-the-world-but-ai-is-going-to-eat-software/

“Software is eating the world, but AI is going to eat software.”

To be 100% percent honest, I initially avoided Machine Learning when my boyfriend first suggested to me months ago because I didn’t think I was “smart” enough to do it.

I thought to myself “What’s the point? I’m never going to be good at it.”

However, realizing the importance of keeping a growth mindset, I’m no longer scared to take on this challenge.

Though Jensen Huang specifically mentioned the rise of AI in self-driving cars and the health care industry, AI is not just limited to big companies like Google and IBM.

Once I started paying attention, I noticed machine learning being adopted everywhere.

Even at Pillow, a small startup with less than 10 engineers and around 30 full-time employees, we’re already starting to use AI such as image processing to solve key problems.

With so many free online resources from Coursera to MIT OCW, there’s no financial reason to not take a course. As for myself, I just started the Machine Learning class on Coursera taught by Andrew Ng.

And there it is. The list of things I do to grow and be more effective at work.

Originally published on Pillow.codes Image from here