softie-ramble

How a few good years can make or break your software career

Luck is when preparation meets opportunity.

What percentage of my success can be attributed to meticulously planned hard work, and what remaining portion is through luck?

Sometimes I wonder the same for my peers who've achieved a higher title than me — did they just get the right projects to grow and flex their skills? Or are they just that much better, efficient, contribute larger impact?

On the other side, for those that failed to achieve their promotion goals: did they just have a bad manager who didn't assign them relevant project work, create a fertile learning environment, or shield them when they are at their most vulnerable?

I've had 10 managers in the past 10 years. I could imagine a parallel universe where I've had fewer managers over the same period of time, and accrued enough social capital and good will with leadership to get a least 2 or 3 years ahead of where I am now.

I guess I'll never know; though I'm quite lucky to be where I am despite this.

To me, a staff engineer is a senior engineer with increased scope and influence.

In my current role, I try to focus on leveraging my expertise and experience to have an outsized-impact compared to what I can do alone.

It doesn't mean I'm technically more capable than all of senior engineers in my company, and that's okay. I've learned to accept that I can't know anything and everything, and it's okay to say 'I don't know, give me a couple of days; here's who might have the knowledge to help you, and if not I'll look into it with you'.

How would you even begin to measure that anyway? You can't quantify your entire set of theoretical knowledge at your disposal, or quantify completely the quality of the application of said knowledge.

I try to make connections and chat with people outside my immediate team and org; to have a higher resolution picture on the pieces that make up the company.

I write more than probably most of my cohorts at my company. I am happy to see that 50 people or so have read my system breakdown. It means more people now have that knowledge in their minds than before.

I tried to participate in hiring (but the training sessions stopped due to hiring freezes — what can you do).

I speak up in meetings. I acknowledge when a good idea is thrown out, and I steer engineers away from bad ones.

I do not exert my authority onto others, as I have none, and that's okay. All the title brings me is a recognition of my experience by fellow staffers at the company.

I get comfortable in expressing my opinions on matters, if not to convince others that I am right, than to have my opinions changed after being informed through debate.

I start to think about organization health and gaps. I start to think about change at scale.

How to get to staff as a senior engineer

There's no real easy answers. But https://staffeng.com is a good resource on all-things staff engineer related.

What goes from here

You can switch over to the PM or Management track, or you can continue to expand your scope and influence and strive for senior staff or principal (once again, depends on how your organization defines these levels).

For me, I'm currently considering moving to management. I'm getting old and I would rather have the young talents do implementation and tech work.

I get so much joy in mentoring others and seeing them succeed.

An organization's cohort of senior engineers are the ones that get stuff done. They design and implement systems to solve the hard and important problems, and mentor and act as role models to other engineers.

You'll be working on designing systems, teasing out complexity, breaking tasks down for more junior engineers to sink their teeth into.

You will start to become 'the' person who knows technically the most about your systems. Managers will look to you for advice.

Senior engineers should strive to look out for their system's future well being, and act as a counter-balance to management's and business' desire to implement something as quickly as possible.

That being said, you should understand that the goal of a software engineer in an organization is to enable the company to meet their business goals; software engineering and developing systems is a means to this end. Don't forget that business revenue is what pays you and your team.

If you have concerns about your system performance, make sure to make it known to your manager. It won't hurt to include performance and monetary impact if not addressed, if you have those figures.

On progressing past senior

There isn't an expectation that individuals at the senior level will need to develop further to hit the next rung on the ladder: 'staff' (or principal, or tech lead, etc. there isn't a standardized role label for the ones past senior engineer...).

There also isn't an expectation that the senior developers will need to transition into a management role either (though I think most companies only offer this state transition starting at the senior level).

#tech #career #sde #swe #engineer #software

By this time, you would have no doubt been exposed to and have gained much experience in the fundamentals of software development.

You would have begun to start recognizing patterns on the right way to do things, and so called code-smells on anti-patterns that tend to lead to complication and problems.

At this level, you'll leverage your skills to focus on problems at the product or feature level. This is in contrast to your previous job level as a junior engineer, where the scope would have been limited to the implementation (to follow the spec) of a specific nature.

This could manifest into tasks like: – implementing a feature into your existing system – making improvements to your system – generating system and application metrics; monitoring and alarming on performance – regularly participate on an oncall rotation – contribute to hiring and talent management / growth

This doesn't mean that you will stop working on bite-sized code, nor does it mean a junior engineer won't immediately start contributing to a new system design. These are just the 'baseline expectations' of the role.

As an anecdote, three months into my stint as a junior developer at Amazon, I was tasked with designing, implementing, deploying and monitoring a custom file-distribution mechanism to populate our remote application's in-memory pre-computed cache. This is mid-level work.

Three months into my promotion towards a mid-level engineer, I was configuring data and job pipelines and helping out in implementing tasks for my teammates.

In general, as you go up the ladder in job seniority, the scope of work increases in complexity and ambiguity. Past experience and wisdom will be important towards informing your system and application design.

Leading up to my full-time employment as a junior software engineer at Amazon, I've had a couple stints as an intern. The work terms each comprised of 4 months of focused work. My manager and mentor would work together to define the scope of the project and tasks I would implement by term's end.

The main measuring stick at this time of success, and a return offer would be: how closely the actual deliverables aligned with the expected milestone dates. If there was a deviation, were the circumstances / situations that presented itself reasonable enough to give context around the late deliverables.

What's equally more important is the intern's ability to follow instruction, listen to feedback, implement them, and how they presented themselves. As a golden rule, don't be a dick.

I returned as a junior engineer in 2013 in the summer. The days were long, black-eyed-pea's songs kept punishing my ears. My work day starts and ends with an hour commute to and from Toronto downtown core. The smell of cinnamon buns when entering the concourse would put me in a good mood. I grab some coffee, head into the office, greet my coworkers for stand up, and get to work.

Expectations

The expectations as a junior engineer are pretty well known. It involves gaining skills in the following areas: – write code, tests and deploying – learn from others through code reviews, interactions, and meetings – learn verbal and written communication skills – write stories and tasks, estimate points, learn SDLC – scope project, propose solutions, write ups

I needed to be in LEARNING mode. Personally, I felt the hardest part is to balance between relying too much and not enough on my coworkers. If you ask too few questions, and you'll waste hours not getting anywhere; if you ask too many questions, you won't learn to feel comfortable with the unknown and risk being a nuisance to your more senior engineers. I think having a conversation with your manager on this topic should provide some you a reasonable frame of reference on what they expect.

Lifestyle

There are countless articles, videos on how to save money. Instead I think along the two axis of saving for your future, vs. spending to garner experiences.

Being in this industry as an software engineer, this will probably be your first taste of financial freedom (student-loan-debt withstanding). You probably won't have more free time in your working life than now — make the most of it.

Spend time with your friends (or to make new ones), discover activities and discover your city.

Try to limit spending on material / consumer goods. It only makes cleaning up, selling them and moving more difficult. At the end of the day it'll just make your wallet lighter.

Now that I've been in the industry for 10+ years, it's interesting to think back about my journey from junior to staff engineer — the expectations I've met, fallen short of, and striving to meet at each level.

My progression looked something like this: * Engineer Intern: up to 2013 * Junior engineer: 2013 – 2015 * Mid engineer: 2015 – 2018 * Senior engineer: 2018 – 2022 * Staff engineer: 2022 – now

At each progression level, the responsibility of the problem to be solved may increase in complexity, ambiguity, number of dependencies, or a combination of.

I think I'll make a blog post detailing some of my learnings at each career level, and in doing so will help accomplish my goal of writing more this year.

#tech #sde #swe #career

Continuing on with my tradition of setting yearly themes instead of goals, I started off the year with setting my yearly theme around challenge. My hopes of challenging myself, is that I would come out the year stronger, more learned, and more successful in public and private life.

Challenge means any number of things. God knows how many things I started just to quickly abandon. Still, I now look back at the year gone past with astonishment as I recount some of my accomplishments:

• I was able to leave my previous FAANG job for another that pays better, and treats ICs and their time with more respect
• I was able to move out of the downtown core for a slower and freer pace of life, despite that the housing pricing in Ontario / Canada / North America is getting out of hand
• I was able to learn and work on real-life skills that come with owning land and property
• I was able to start experimenting with sleeping better by drinking more water, and less caffeine
• I was able to incorporate reading non-fiction books to both expand my technical + interpersonal knowledge, and prepare my mind for rest
• I was able to make and maintain more meaningful connections with others

Many of these lifestyle changes will grow and compound onto itself in this coming year. I can only hope 2023 will be just as fulfilling as 2022.

I'm not sure what my theme of 2023 will be just yet, but perhaps writing would be one skill that I exercise more...

The lastpass breach has blew open the flaws of cloud-based password manager.

I am now looking for password manager alternatives that are offline-first, with added benefit of allowing local-sync for backups.

Why is interviewing for software developer jobs such a PITA?

There's so much to cover, that by the time I go through the main materials once, the subject matter near the beginning of my study session gets stale again.

Why can't professionals that have been in the industry for some time just let their experience / tenure do the talking?