(Not So) Basic Instinct
Nurturing Problem Solving Instincts in the Tech Industry
Nature versus nurture is an ongoing debate as to whether human behaviours are driven by inbuilt natural factors already there, or are formed through environmental factors such as parenting and life experience. When considering the skills required for building software, or indeed anything else we do in life, you always wonder if it’s always been there or built via experience.
Other life events and experiences make us better technologists, including parenthood, caring, traveling, and being just a friendly human. I always remember chatting about my upcoming parental responsibilities with a friend. You’re never sure if you’ll be a good parent or not, and feel the weight of responsibility in looking for a tiny helpless human. My friend reassured me that the hidden kernel subroutine will kick in when you’re ready, which I found amusing and reassuring. Thinking about that story now and how my now 3 year old has turned out (shock!) leads me to realise that some instincts were there, but a lot of the instincts formed through practical experiences such as trying to get them the baba to sleep at 3am, or learning tricks from my husband how to get a slippery toddler out the bath (true story).
Over my 11 year career in tech, I’ve noticed with each move I become more comfortable with uncertainty, and find my feet more quickly than with the last move. It is my opinion that through my school, university and software engineer career I have built instincts through trying, failing, adapting and learning from others. Here I reflect on the main types of instincts I’ve nurtured through my technical career, and share tips on how you can build these instincts too.
Helps Me Help You
You may not know this, but my first role straight off my 15 week training program within the bank was a rather mixed role. I was a developer reading rather than writing Perl and coding in Python, SQL and AxiomSL (aka a data management platform with an in-built ETL used for financial domains such as regulatory reporting, capital reporting and liquidity management calculations which now looks to be part of the company Adenza…). However, I also supported the calculation and submission efforts by users in production. Normally, as I came to find later, these roles are not normally combined.
This dual responsibility definitely made me better at multitasking, or at least I think it did. I know from psychology But it also introduced me early to the need to prioritise my work. This was a slightly different experience to my peers who didn’t have the same support commitments when starting out. If it got to them as an urgent escalation, it was a drop-everything situation. Yet for me it was more nuanced. Submission issues were a red alert situation, absolutely! However, some user production questions were a mere DEFCON 5 situation, or for those who haven’t learned the lingo from Mr R’s love of Star Trek, not a big deal at all.
The context was important in determining the priority. This taught me early the importance of asking questions. Just like an hospital emergency room scenario Darria Long discusses in her TED talk, the loudest patient is not always the highest priortity. Issue triage typically involved me asking questions to categorise an incident such as:
- What environment is this issue in? Production may be critical depending on impact, but QA may not be depending on whether they are using it for upstream application verification compared to testing adjustments before applying them in production.
- How do you expect this logic or feature to work? Differing expectation versus reality is still something I see even today as a Developer Advocate.
- Do you have any screenshots or error messages? This question still proved useful later when I transitioned into web frontend development.
- What is the impact of this issue? Knowing if this impacts an external submission today versus internal reporting was a key indicator of priority for me at that time.
When it came to requirements prioritisation this was my first insight into the subjective nature of importance. Sadly I got stung a couple of times when focusing on building something when they wanted me to focus on another requirement resulted in some uncomfortable questions. When you first start as an engineer, you want to please users and establish a reputation for delivery.
Every issue is important to someone. Therefore, depending on who you speak to it’s easy to be led astray and focus on building the thing to solve the problem, especially if it’s easy and you’ve built confidence in the technology you need to use. It highlights the importance of building in small increments as advocated by agile principles and agreeing on a common strategy as a team, rather than working in waterfall as independent units, and not discussing priority enough.
An Honest Mistake
Instincts on the root cause of errors is another skill that requires nurturing to master. When I moved to be a frontend web developer, I learned the importance of reading and interpreting error messages and logs. I indeed had to read logs and interpret error messages when things went wrong. However, what made this different is that this was my first tech stack move. At this time I was learning Angular, Typescript and many other different technologies.
Anyone who’s done any web development in the last 10+ years will be aware of the framework and tooling explosion in that space. It can be intimidating to pick them up as they often have their own opinionated patterns you need to follow. Angular in particular enforces very strong structure and style if you check out the style guide. In addition to learning new terms and patterns, you also need to develop instincts for reading and processing stack traces emitted when things go wrong. While advancements in recent releases have improved the developer experience, such as the improved developer experience for the banana in the box error introduced in Angular 14 in 2021, the reality is that diagnosing error messages is an art that we hone instincts for with each feature we build, and through researching and understanding the intricacies of how they work under the hood.
We also get better and researching issues and building search-fu to understand the relevancy of information we find. When you start as an engineer, you may be more likely to reach out to a mentor to help with confusing error messages first. However, later as you get better at using Google, or your favourite alternative search engine, you get better at finding not the exact error message, but find related messages triggered from other libraries and from there and generate ideas on how to solve the problem at hand. These skills have proven not only useful in my role as a developer. As an advocate who looks to build content and show via prototypes the features of particular technologies, diagnosing and fixing error messages, possibly in unfamiliar ecosystems, has helped me learn Elasticsearch and the technologies I advocate for quickly, and continue to keep up to date with them.
Human After All
A common career path within technology, but not the only path, to engineering management also requires learning. While often this progression is suggested as the default path, it is a role I believe requires building specialised skills that also need to be grown. Just as I did as an engineer, as a manager I engaged in research, training and reading to build the skills required of a good manager and technical leader. Let’s not confuse leadership and management. They are not the same thing.
Stepping into management can initially be a fearful construct. Breaking people seems far easier and scarier than breaking software. For me, I found the need to build my empathy, delegation and teaching skills to be a better people manager. There is also the need to get up to speed with company policies, such as sickness, performance and parental policies, and resources for career growth and mental health. As a manager, you need to support people through life-changing events and ensure they can bring their best and authentic selves to work in good times and bad. My first time supporting a direct through personal challenges was hard, and I feared making it worse.
The best advice I ever received was to treat people like a human first. Since then I’ve learned practical skills such as active listening that support that human first notion. Use your humanity as your driving instinct, and you should be able to support people.
I Gotta Feeling
With any job move, it can be difficult to generate instincts on your remit. When changing careers, or moving into a new domain it can be difficult to figure out if something is of benefit to the community you serve. I’ve found that moving into DevRel that events have varying target audiences, from developers through to executive levels. It is not always clear-cut who they are aimed at, which events are relevant to which communities and which content would be of interest to those communities.
Events have different audiences, and building the spidey sense for which ones appeal to developers is hard. Recommending content and events for audiences that are not the intended target can leave communities uncomfortable. I’ve experienced representing my company at events and being given the sales pitch when the reality is I don’t have the authority to commit to purchases. I’m sure current and former Vice Presidents working as software engineers within financial institutions will all know exactly what I’m talking about. For those unfamiliar, VP is not board-level but the first rung on the promotion ladder. I use that experience and empathy, along with guidance from more experienced colleagues, as the basis of the Litmus test I use to classify developer and non-developer events.
When speaking and writing content, I also need to ensure the topic is something I can speak on as an authentic authority. Much of my experience as a frontend engineer means I use technologies and solve problems primarily with a frontend rose-coloured lens. I can also dabble in domains related to my experience such as Java and Observability given my limited application support experience.
I personally will struggle to give concrete recommendations on operational and security topics given my lack of experience and expertise. I try to ensure I give my genuine opinions and experiences of using tools, or how I would use them to solve problems I have previously encountered. I also need to be aware to also share my experiences and guidance on topics such as diversity and technical leadership as well as products of the tech company I represent. I am passionate about being a well-rounded and empathetic software engineer and building others by sharing my experiences and learnings through 11 years of building software.
Mother Stands for Comfort
Looking back at these experiences, I see merely a subset of the different hats I’ve worn working in the software industry for 11 years. Like my journey through motherhood, all the instincts I have gained through successes, experimentation, failure and reflection. Even now I’m still learning and honing new instincts as I build software and write content. Each new insight helps me to form a gut feeling about what is right or not for me in a given situation.
You may not think you have instincts, especially if you’re worried about being found out as the impostor in your team. Trust me, they are in there! They may not have always been in there since your inception like that mythical motherhood kernel subroutine I searched in myself for at the start of this story. But trust that you can build your own instincts, and use the guidance and help from others to nurture them further. Trust your gut as it evolves over time. And if it doesn’t work out, learn and try again!
Thanks for reading! Do reach out if you think of other instincts and lessons you have learned that I too could learn from.
Originally published at http://carlyrichmond.com on October 18, 2022.
