Maturity and mastery as an engineer and employee
There are three topics that I'd like to discuss:
Maturity as an engineer
Mastery as an engineer
Mastery as an employee
1. Maturity as an engineer
First, maturity as an engineer. Imagine that it's 100 years in the future. The world has changed dramatically and humans have evolved into a super race of software engineers. Everybody programs. Small children write programs to clean up the dishes. At the helm of this super race is a massively talented distinguished engineer who is accountable for the software that ensures the survival of all human kind.
BUT! There might be a problem. This engineer is about to retire. What will humanity do without this person? Who will answer crucial questions about why certain decisions were made? Or why the code looks a certain way? Or the subtleties of different product features? Who will be able to ensure new products ship without this engineer driving the system?
The answer is easy: any capable engineer.
It sounds like madness, but it’s not. Take a moment and picture in your mind this massively talented engineer, who is so distinguished as to be trusted with humanity’s survival. Can you imagine that they did not –
Write good commit messages including links to the project tracking system
Update the project tracking system with succinct, informatively comments in a timely manner
Always create distinct tickets in the project tracking system for each distinct unit of work
Document in the code
Document in the team docs platform
Provide insightful code review feedback across the many facets of good review (see my Looking for a code review? 4 tips to set yourself up for success)
Mentor others
Give technical talks and share the resources afterwards
Do everything in their power to learn how to create well designed code -- and continue to learn
No, an engineer so distinguished would be sure to thoroughly do all of that – and more. So, when this engineer retires, they are not in fact leaving completely, but instead simply no longer attending meetings or contributing new work.
The takeaway? → Maturity isn't a binary characteristic. It is a long spectrum, with those on the far end of it making the workplace a far more productive and sustainable place for everyone.
2. Mastery as an engineer
Next up, I want to discuss mastery as an engineer. If our goal as engineers is to produce working products that delight our users, then given endless time and resources, we would always achieve this without problems. There would be no bugs, no scaling challenges, etc.
In reality however, business time and resources are limited. So the challenge is to develop solutions as quickly as possible without sacrificing quality.
When I talk with engineers early in their careers, they are often awestruck by how quickly senior engineers can develop code and fix problems. "That engineer is so brilliant," they remark.
The truth may not be so. That senior engineer may be just an individual of average ability. They are differentiated from their peers of fewer, greater, or similar years in the industry not by brilliance, but rather by one crucial investment. That engineer invested in mastering their domain.
To provide some examples, consider the following –
Master their toolchain: PyCharm, the terminal, git, network requests, profiling, DataDog, etc.
Learning how to isolate the problem. Database call acting funky? Check out the actual SQL that is being generated. The faster you can get feedback, the faster you can create a working solution.
100% Confidence in their work (article pending).
Taking the time to deeply understand the requirements -- what is being asked and as importantly what is not being asked
3. Mastery as an employee
Finally, Mastery as an employee.
Just like our goal to get good code written quickly, as employees we want to achieve our non-coding activities at high quality and without delay.
So what's the toolchain for an employee?
Invest in good IT set up at home
Invest in your writing: Grammarly, textio, dictionary app
Invest in your speaking, start with succinctly getting your idea across (Bard can help!)
Learn how to use your project management software
Learn how to use your communications software (e.g. Slack, Gmail, Zoom, etc.)
Learn how to prioritize your TODO list. Hint: PIE is an amazing, adaptable framework.
Learn to read facial cues when you’re in zoom meetings so you know when you can talk and when others are about to / want to
Stop making excuses to yourself about why you couldn't do something with a tool -- you can learn how to do it. Find someone who knows how and commit the time to learn from them.
3.2. Mastering the human side
Beyond your toolchain, there is another side to mastery as an employee. That's the human side. If you consider the greatest achievements of humankind, all of them have happened through supportive collaboration and cooperation. We see this easily in Sports Teams, but for some reason when it comes to our job, far too few companies and far too many people invest in supporting and collaborating with each other. It's huge miss.
When we do support each other and when we do work together, we achieve better results and happier employees. This is one area in which I have always been proud of the teams I've built in Engineering.
A short list of behaviors that I feel contribute to mastering a supportive working environment are for each of us to,
Reach out to other people to say "Hi," "thanks," or prop up. One sentence is all that's needed!
Ask for help
Give help, whatever small amount you can
Don't Do Nothing when you see problems
Over-communicate
Don't be quick to judge; assume good intentions -- Hanlon's razor
Catch people before or when they fall -- offer help
Take risks and be vulnerable
Believe in yourself and learn from failures
Learn how to give feedback and then provide feedback (ask for help if you don't know how)
Don't harbor resentment
Talk about elephants in the room
Learn how to hear and improve from feedback
Remember: "We judge others by their behaviors, we judge ourselves by our intentions."
Comments