What stood out to me was how these tools changed where people spent their time. Engineers using these tools tended to be domain experts on the systems and they were modelling. They focused on behaviour, edge cases, system design and verification. Our tools enabled fast design exploration, and when they were confident, the tools generated the code.

That model works because the complexity of these systems and the cost of mistakes in these contexts is high. Writing code by hand does not scale. With Model Based Design, the model became the spec. You can run it to understand the behaviour of the system and catch problems before they made it into code or hardware. The result is trust and confidence in the system being built.

Jack Little’s (MathWorks co-founder and CEO) talk about the history and impact of Model-Based Design is a must-watch. What MathWorks tools enabled control system engineers to do has some parallels with the benefits we’re starting to get from the use of LLMs and agents in traditional software development.

Here’s a slide from the talk, which if looked at in isolation, might have come from a presentation about the benefits of LLMs for code generation (except for the “executable specification” part - for now!):

Fast-forward 8 years

Over the past few weeks and months, I’ve increasingly been a part of conversations about the effects of AI on the software engineering profession.

How does it benefit engineers at different stages of their careers? How does it affect roles that are software engineering “adjacent”? How do we help software engineers - particularly those early-in-career - build judgement and expertise on technical systems? Are we moving to a higher abstraction level of building software?

With LLMs and agents as our code generators, we’re spending less time typing out code. The focus has shifted to:

• Being clear about what the system should do.

• Understanding the domain - Necessary, because a lower understanding of the domain makes it harder to verify if generated code only looks right, or is actually right.

• Thinking about testing and validation to guarantee the correct behaviour for the operating conditions (inputs, context) we are designing for.

• Maintaining context - markdown files containing an overview of the system, sequence diagrams, coding standards, security and quality preferences etc. - that help constrain LLMs.

Since code generation speed isn’t a bottleneck anymore, you can try variations of your designs and implementations in minutes - pushing on performance, adding constraints and exploring tradeoffs.

It starts to feel a bit like working with MBD tools instead of writing everything from scratch.

This is where some of the old ideas from Model Based Design start to matter again. Clear specs. Early validation. Tests that reflect real behaviour. Ways to verify what was generated. Strong security boundaries.

Marc Brooker wrote a great post recently on spec driven development that gets at this from a software angle - about specifications being at the core of an iterative software development and design loop.

Software engineering isn’t turning into Model Based Design overnight. The tools and workflows are different. But the direction feels familiar. We are moving toward a world where we shape behaviour at a higher level and rely more on systems to fill in the details.

In Righting Software by Juval Löwy, one idea stood out to me: Volatility-based decomposition.

The premise is simple: “Decompose your system along axes of change.”

Change here refers to areas of high volatility. Volatility means the potential for large changes that might have a ripple effect across the system (or systems), not small variations that can easily be handled with conditional logic.

What are some examples of volatility that need to be modeled when architecting software?

• Business rules

• Pricing models

• Regulatory logic

• Integration contracts

• Customer configuration

• Reporting formats

• Detection / scoring / remediation algorithms

These elements evolve at different rates and for different reasons.

Volatility-based decomposition suggests that if two parts of the system change independently, they should be isolated from one another. The discussion shifts from “How should we structure the code?” to “How do we prevent change in one area from cascading into others?”.

Change Speed Is a First-Class Requirement

The ability to change quickly is an unstated requirement for most software, especially platforms that hope to gain a dominant position in the market or support a small but dedicated customer base reliably for a long, long time.

It’s not a stretch to say that the speed with which we can make changes to our software influences:

• Market competitiveness

• Customer retention

• Product learning cycles

• Organizational morale

When volatile concerns are tightly coupled, every change expands regression risk and coordination cost. It’s natural in this situation for engineers to become cautious. Planning cycles and discussions stretch endlessly while delivery slows.1

In these situations, engineering cultures often become protective of stability. Change requests are evaluated through the lens of risk and effort. That instinct is understandable when the architecture amplifies change.

Contain the change

When volatility is isolated, teams can evolve parts of the system independently. The has the effect of localizing risk, making change easier to reason about and accelerating our ship-learn cycles.

One way to frame architecture discussions and efforts, especially at the start of major projects is that the architecture should limit and confine the effects of change.

When boundaries align with volatility:

• A regulatory update affects a specific module.

• A pricing modification does not ripple across unrelated domains.

• A new integration leaves core business logic untouched.

Change continues, but its impact is bounded.

Containment reduces coordination overhead, cognitive load, and unintended consequences. Teams can operate with greater autonomy because responsibilities are clear and the blast radius is limited.

Predictable value delivery at speed depends on this containment.

“Features Are Aspects of Integration, Not Implementation”

This was another takeaway from the book. The idea of “Manager” and “Engine” components (along with clients, resources, data access layers, utilities) where most parts of the system can be expensive to build and must be built with care, but “Manager” components orchestrating all of those parts must be built to be “almost expendable”.

Customers do not interact with implementation details. They experience workflows, policies, and integrations.

A feature often represents:

• A new workflow composed of existing capabilities

• A policy applied to existing signals

• An integration with another system

• A configuration that alters behavior

• A new aggregation or presentation of data

When systems are structured using traditional functional decomposition or domain decomposition techniques, features tend to cut across boundaries with delivery requiring synchronized changes across those boundaries.

When systems are structured by capability and volatility boundaries, features emerge from composing stable building blocks. Existing components are integrated in new ways i.e. “Manager” components are born, change and die with ease.

Key Insights

• Architectural agility influences competitive position. Organizations that can evolve safely and frequently learn faster and respond more effectively to market shifts. The impact compounds over years.

• Volatility-based decomposition requires domain awareness. Architects must understand which aspects of the system change independently and why. This demands close alignment with product strategy and business context.

• Clear boundaries and stable contracts are essential. Leaky abstractions increase coupling and erode the benefits of decomposition. Early discipline creates long-term flexibility.

• Change is the default state of software and architecture shapes how that change propagates. When change is contained, teams move with confidence and speed becomes sustainable.

• I can see codebases that leverage volatility-based decomposition being worked on more easily by Agents, and I can see those codebases experiencing a tailwind of velocity. Changes to a single file, a single module, or a very small set of files in a codebase decomposed based on volatility have a lower chance of falling apart and going off the rails than Agent sessions that would need to make changes spread across multiple modules and dozens of files.

Sharpen(ing) the saw is generally good advice for people in all professions. Particularly in industries where the pace of change is high, and if you’re not sharpening your saw, at least some of your skills are atrophying.

So it is for people who work in / with technology. There’s plenty of good advice out there for how to keep your technical saw sharp from folks like Jeff Atwood and Scott Hanselman.

What happens when people transition from the role of a software developer to a manager? Some energy continues to be poured into keeping that technical saw sharp, but the motivations vary:

1. Love for the learning and intellectual stimulation that inevitably comes from keeping the technical saw sharp.

2. Wanting to keep the option of switching back to an IC role.

3. Not wanting to see a hard earned skill (often over many years) wither away with time.

4. It’s the only “saw” some people can see, so naturally, it’s the only one they can think to sharpen.

Be especially wary of that last one. While the mechanics of moving into a management role might have come about through a promotion, this is in reality a different job. A different role with a different set of expectations (although many companies and individuals in the role might still treat it as an “engineer with direct reports” role).

Congratulations, you now have another saw to sharpen!

The saw of skilled management. The saw that - yielded well - will:

• Forge a high functioning and highly committed team

• Produce an environment of growth and fulfillment at work

• Be a multiplying force (for good) for the organization

The tools that helped you sharpen your technical saw won’t necessarily work for the management saw. The underlying drive to learn and grow is the same, but sharpening the management saw must be done with intention.

All I’m saying is:

• Be aware that you have another saw to sharpen.

• The new saw works very differently, it’s impact is often felt over longer distances of time than the technical saw. Don’t discount it, or dismiss it, just because it might be more ethereal or abstract to wield.

• You might find it difficult to be an effective manager if you aren’t sharpening the management saw, working with a blunt and ineffective instrument, getting frustrated because you didn’t even know it was something you had to sharpen. Sharpen both, by all means. But balance your energies wisely.

I’m often asked by people newly transitioning into management whether their technical skills will atrophy. I can’t possibly answer that question for you. It depends on your individual context, and the energy you spend continuing to keep that saw sharp. “Technical skills” means a lot of different things here, and that topic deserves its own post.

However, in worrying about what you might lose, don’t forget about you will gain.

The words “estimate” or “estimation” are often met with skepticism by teams building software. In the software industry, there’s a tendency to get caught up in the “how”, or the right / wrong ways to estimate. We get distracted by the mechanics of it, and don’t always seek to understand the principles behind it.

I have seen teams break down large initiatives into atomic units of work, where each unit attempts to represent a small and fungible (among the team) piece of work - let’s say one day’s worth of work.

I have seen teams consider the practice (of estimation) to be ineffective and abandon any attempts at estimation.

Why bother with estimates? Who needs these estimates and why?

You might hear something along the lines of:

“We estimate so we can generate forecasts! It’s important to be able to communicate the cost involved in building a feature / capability / product. We do this by breaking down the thing we need to deliver into increasingly smaller ‘units’ of work until we’re able to generate high-confidence estimates for how much work each unit is going to require.”

“The more we estimate as a team, the more accurate we will become with our estimates over time. We will understand the team’s throughput, and we’ll be able to offer high predictability over what we can ship, and by when”.

However, this perspective makes some assumptions:

• That the effort needed to execute on something is equal between team members. Capacity is often not fungible. Answering the question of “how much effort do we need to build X?” can produce variable answers depending on who is doing the work.

• That projects can be broken down with a high degree of granularity, all at once, producing homogenous and atomic units of work. There’s a limit to the granularity with which you can break down a project. Early in the timeline, there can be many unknowns which limits the confidence of the predictions. Trying to break things down into increasingly smaller pieces to produce high-confidence estimates can lead to wasted work if the approach or requirements change. The more upstream the change, the greater the domino effect on estimate changes.

• That the point of estimation is only to produce forecasts or plan for capacity, while discounting the value derived from collaborative estimation and conversation, to shed light on mismatched assumptions, misunderstood requirements, missing dependencies etc.

• That estimation is a one-time exercise at the start of a project, never to be revised or revisited. That would be like a weather app that made weather predictions a week ahead of time, and then never adjusted those predictions.

• That estimates will become increasingly accurate over time. This may be true for teams where the nature of work seldom changes, but in practice I have rarely seen this state (of high precision estimates) being attained and maintained. Teams executing on a lot of novel or innovative work are unlikely to attain this state at all.

All that said, businesses need to make money, and they need to do this by creating value, at a sustainable pace and cost, while trying to do it all more effectively than their competitors. The ability to forecast when that value will be delivered, make prioritization decisions and move nimbly is therefore invaluable.

I don’t have a prescriptive solution (context matters after all), but I try to lean on some principles:

• Understand your constraints (time, quality, cost)

• Be aware of your assumptions

• Know your team’s skills and capabilities

• Treat your estimates as forecasts, not timeline commitments. Forecasts evolve, commitments don’t.

  • Consider associating forecasts with confidence numbers (communicate the degree of uncertainty around your forecasts)

• Strive for clarity over the short-term / tolerate some fogginess for the long term

• Estimate collaboratively - the value is in the discussion

• Lean on a “push” model for communicating forecast updates, particularly forecast changes (think weather “alerts”)

• Be curious, not emotional, about forecast changes

I couldn’t dance to save my life, but it doesn’t require proficiency in dancing to see the grace and fluidity with which some dancing partners operate. This got me thinking - Unfortunately, I do tend to go down arbitrary thought rabbit-holes - that there’re some things in common between being an effective dance partner, and having an effective relationship with your manager.

Things that come to mind include:

• Attentiveness - If you aren’t paying attention to each other’s body language, it becomes harder to correctly anticipate next steps and stay in rhythm. There is dissonance instead of resonance.

• Improvisation - If you fall out of rhythm, even for a brief time, recognizing it quickly and improvising is key. Improvisation in this context doesn’t mean winging it! It means recognizing that things won’t always go to plan, and having the presence of mind to be open to possibilities, while recovering and continuing gracefully.

• Clear communication - No explanation needed. Both sides need to be clear about what they value and their expectations of each other.

• Cooperation - Individuals who are in it for their own personal glory are unlikely to succeed (certainly not in the long term). Instead, a certain degree of empathy and connection is required, with a clear understanding of the goals that the partners share.

• Practice - Dancing together effectively takes daily work and practice. Ignore the routine / relationships for too long and decay is inevitable.

• Trust - Is foundational to it all. You trust each other to be attentive, flexible, improvise when necessary, communicate clearly, and put work into the relationship for it to fully meet its potential.

The power dynamics of the relationship are obviously very different i.e. there’s only so far you can take this metaphor. Even so, the overlap is interesting.

Short and sweet. Thanks for reading!

It struck me recently how often I see the words “empathetic leader”. Sometimes, this is an individual describing a former manager. More often, it is someone describing themselves as having an “empathetic leadership style”.

What does it mean to be an empathetic leader? Imagine you’re at a supermarket and you see an “Organic” label on a food product. All it takes is a label or sticker to make the claim, but how do you know for sure?

I have personally understood empathy to mean that one is sensitive to (and understanding of) the experiences, feelings and thoughts of others. It is a way of being. It is not a style to be tried on and discarded, and it’s not something to aspire to only when it is convenient for you.

In my experience, empathetic leaders are:

• Good listeners, with great follow-through

• Open to feedback, and act on the feedback

• Care about you, and more importantly, respect you enough to be candid with you

• Clear about their expectations, and transparent about their actions and decisions

It’s a high bar to meet, but it comes down to having firm values and principles and seeking to exercise those principles consistently.

What does empathetic leadership mean to you? What are some other principles that you’ve seen empathetic leaders follow consistently?

If you’re in a situation where you get to interview your future manager, consider asking:

1. What’s some feedback you’ve received recently? How did you act on it?

2. Can you tell me about a difficult conversation you had recently? What made it difficult? How did you deliver the message?

3. How will you set expectations with me? How often will we revisit them?

4. Can you tell me about a decision you made recently? How did you communicate the thought process that went into making the decision?

“Empathy is about finding echoes of another person in yourself.” - Mohsin Hamid

I have had numerous conversations over the years with friends and colleagues looking to move from Management to Individual Contributor (IC) roles.

This isn’t going to be a post listing all the “right” or “wrong” reasons for a Manager to IC transition. Nor do I want to talk about the merits of making the switch. You’ll find plenty of opinions and resources about the role switch online, often referred to as the engineer-manager pendulum. I made the transition from Manager to IC in 2018 myself (and then went back to being a Manager in 2019), but the mindset was one of moving towards an IC role as opposed to moving away from a management role, all to support some technical aspirations I had at the time.

Instead, I want to focus on a specific pattern I see (or hear about) when I speak to people in management roles considering the switch to an IC role. I often hear:

• “I miss the satisfaction of shipping code”

• “I used to be able to tell how much work I got done.”

• “This whole week I attended meetings, read documents and responded to a lot of questions! I don’t think I could tell you what I produced.”

These sentiments might be expressed by someone who truly misses writing software, the accompanying state of flow, and the feeling of accomplishment from seeing software you wrote bring value to customers.

However, it might also be that the person isn’t missing the act of writing software, but is instead missing evidence of producing tangible and easily measurable outcomes and artifacts.

What’s My Impact

As an IC, it can be easy to see impact via Pull Requests merged, new systems or components created or rearchitected, and value delivered to customers. How do you see and experience the impact of your work as a manager:

• In the short and medium term, you might be asking - What did I produce or reconfigure? How did the team / organization / customers tangibly gain from my work this week?

• Over the long term, you might be asking - How does the current state of the team and technology tie back to decisions that I have made or supported? Exactly how has the team benefited from my presence, guidance and decision making over the past few months / years?

If you are a manager considering a transition away from management, consider asking yourself:

Only you can answer that question for yourself, possibly with some help from candid conversations with your manager, and with members of the team you support. You owe it to yourself to think deeply about this question. It would be a shame for you (and your team) to lose out on aspects of management that you love, all because you couldn’t (or did not have the support to) clearly picture the fruits of your labour.

The “replay my thoughts” and “gauge their quality” bits are therefore the biggest motivators behind another serious attempt at regular writing.

I also just turned 40. The older I get, the more I realize how often I tap into and rely on my unconscious mind, and so the responsible thing to do seems to be to explore and surface more of my unconscious into my conscious.

This is particularly important to me as a manager, as someone who has been, is, and will hopefully continue to be responsible for serving my team(s) and the organization(s) I work with.

I expect to write about my experiences and thoughts, around my role as an Engineering Manager in the software industry, towards the goal of leading more consciously, thoughtfully and competently.

If you think this sounds interesting, I’d welcome the company on the journey.

Subscribe now

There’s a lot said online about why we should craft good pull requests, and how to do it. Despite how well accepted this seems to be (bordering on “common knowledge”), I haven’t observed this to be common practice.

I’ve been thinking about this a lot lately, especially since I begin my journey on a new team, at a new company — and since my previous team and current team have very different PR writing cultures. This got me to ask:

Why is it that we consider writing great PRs to be obviously beneficial, and yet we do not see the expected widespread adoption in practice?

Reflecting on my own experiences, I’ll offer my thoughts on some forcing functions that might naturally incline development teams towards producing higher-quality PRs.

My criterion for high-quality PRs is quite simple (but not easy):

1. The team reviewing the PR is easily able to glean the context for the work, this includes newish team members (2+ months) — At a minimum, this should include information about why we are doing this work, how it is being accomplished, and being explicit about risks and assumptions.

2. The work itself has been broken down and structured in a way that makes absorbing the entirety of the changes easy within a relatively short time window (1 hour at the most). Usually, this manifests as well-structured commits that build on each other and tell a story.

The current state of things

There’s no shortage of content on the internet advocating for writing “good” pull requests. Search for:

“Why should I write a good pull request” (365 million results), or

“How to write a good pull request” (601 million results)

And you’ll find an endless supply of opinions and blogs about the benefits of writing good pull requests, and even some guidance around what a good pull request might look like.

For the “why” in particular, the themes across the articles boil down to the following:

• You (the PR author) want to make it easy for the reviewers to understand your changes and help you ship those changes.

• Well-written PRs serve as documentation for future developers (including future you!) around the rationale for certain changes, or the approach taken to introduce them i.e. capturing context.

• A well-written PR provides an opportunity to rationalize and justify your changes, making your thinking clear to others, and giving people an opportunity to challenge your rationale for the changes or the approach you have chosen.

This all makes sense in theory, and yet…

Despite these benefits being widely known and the “how” made easier through mechanisms like PR templates, well-crafted PRs are anything but ubiquitous.

Empirical Observations

In my career so far, I’ve seen some teams naturally gravitate towards well-crafted PRs, and other teams adopt them begrudgingly at best, seeing it as “process” and “paperwork” that distracts them from getting their code shipped.

The teams that take pains to craft good PRs understand the theoretical benefits, but are often subject to subtle influences (behavior shaping tendencies a.k.a forcing functions) that sustain the practice of writing great PRs until it becomes a part of the team’s DNA.

Here are some forcing functions that I have observed and experienced:

1. A team with varying experience/skill levels around the language, tooling, or framework being used to deliver the work. Varying levels of expertise force the simplification of the presentation (the PR!) of that work.

2. Closely related to #1, varying levels of familiarity with the codebase/systems being changed. Everyone on the team may be on an even footing with their technical chops, but they don’t all understand every part of the codebase, therefore forcing the change to be explained and presented well before being merged in.

3. New teams, where team members don’t know each other very well (yet), result in people putting a lot of effort into clearly communicating the “why” and “how” of the changes they are trying to ship.

4. Closely related to #3, a team that is changing often (people coming onboard, as others leave the company or transfer to other teams). This incentivizes well-written PRs as a mechanism to capture and transfer context. Situations like this might be common in companies that encourage high mobility, or the nature of the team necessitates a relatively short tenure.

5. Some teams work with many stakeholders that need to know the context of the work being shipped but aren’t experts in the codebase or technicalities of the work. Product Managers, Designers, and Engineers from adjacent teams contribute to the codebase via inner-sourcing efforts.

6. The codebase has history or context, such that the commits in a PR by themselves are insufficient to tell the full story. OR the codebase represents a system that has complex interactions with other systems, and the change being made must be coordinated with changes to those systems.

What other forcing functions have you seen? Are you an Engineering Manager or team hoping to improve the PR writing culture on your team, and could you leverage any of these forces to shift your team’s culture and practices around PRs?

Resources

1. About Pull Requests: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests

2. Forcing Functions: https://en.wikipedia.org/wiki/Behavior-shaping_constraint

3. 7 Reasons For Good Pull Request Descriptions — https://frontside.com/blog/2020-04-15-7-reasons-for-good-pull-request-descriptions/

4. How To Write The Perfect Pull Request — https://github.blog/2015-01-21-how-to-write-the-perfect-pull-request/

I use the term intentional manager because a lot of engineers find themselves promoted into this position and end up winging it. This can be a result of:

• Organizations not providing clarity around exactly what’s expected of engineering managers

• Previous managers not having demonstrated intentional and conscious leadership, causing a perpetuation of the cycle of zombie managers

• Newly promoted managers not realizing they now need to make the time to more consciously understand and operate in the role

It’s unfortunately all too easy to fall into the trap of being reactive in this role — to feel like the role is happening to you as opposed to feeling in control of your time and priorities.

A small percentage of those promoted into engineering management might be self-aware enough to quickly understand the nuances of the role shift, but that’s more the exception than the norm.

Many new managers end up leading unconsciously — reacting to situations, instead of working in the role with intent and clarity.

Here are a few things I wish I knew when I first started out as an engineering manager.

Allow Yourself to Be Interruptible

I’m putting (what’s likely) the most controversial statement of this article on top! Let me explain: As a successful individual contributor, you were usually only accountable to your peers and your manager. Apart from a few meetings, you could expect to easily make room for long stretches of deep work — i.e., uninterrupted time gaining traction on a task.

As a manager, you have 360-degree accountability — to your peers, to your direct reports, to your manager, and if you’re working within a product group, then also to the product manager and product designer on your team.

It’d be unusual for you not to be interrupted! It’d be especially unfair to your direct reports if you didn’t make yourself available when they were blocked.

This doesn’t mean you should shy away from blocking off deep-work time on your calendar or unplugging from Slack — just do it sparingly and on the tasks that truly need your undivided attention.

Your Success Is Measured by How Effectively You Enable Your Team:

Andy Grove said it best in “High Output Management”:

“A manager’s output = the output of his organization + the output of the neighboring organizations under his influence.”

You’ll find success when you consistently find and focus on the highest-leverage tasks at any time.

As a manager, the highest-leverage tasks are often the ones that unblock, enable, or multiply the productivity of your team.

Individual contributors promoted into a manager role will often fall into the trap of thinking that the manager role requires them to be a 2x (or maybe 5x/10x) version of their individual contributor), and this never ends well.

You’re Not Necessarily the Best Engineer on the Team

Note that I say not necessarily. You might be the best engineer on the team at any given moment in time, but this won’t always be true.

If you have any insecurities about not being the best engineer on the team or feel your imposter syndrome ratcheting up because you think you need to have all the answers, then it’s worth taking the time to address the root of these insecurities first.

The expectation isn’t that you’ll have all the answers, but you should:

• Be willing to help your team uncover the right questions to ask and work with them to discover the answers

• Look to hire engineers who will compensate for your technical blind spots

Try Not To Take On Work That’s on the Critical Path

If your job is to be interruptible and available and you’re therefore unlikely to get fewer bursts of time for deep work, then you should avoid taking on tasks that are time critical. This is particularly true if the slow completion (or noncompletion) of that task will end up blocking your team.

This also ties in with acknowledging that you may not be the best engineer on the team. Why? Because as a newly promoted manager, you may feel the need to prove yourself by taking on a difficult or critical task, only to discover you don’t have the time needed to dedicate the necessary cycles of deep work toward it.

The end result may be one or more of the following:

• Frustration for your teammates

• Falling behind on the schedule

• A severely bruised ego

• Burnout (because you’re effectively trying to do two jobs)

Model a Healthy Relationship With Work

Speaking of burnout, I can’t overstate the importance of modeling healthy work habits.

This includes things like:

• Modeling the healthy use of personal time off from work

• Avoid sending communication or responding to message after hours. As a manager sending out communication after hours, some of your direct reports may experience pressure to respond to your after-hours messages quickly, instead of just waiting to respond the next work day.

• Don’t take yourself too seriously. Be that manager with a sense of humor, willing to see the lighter side of things.

• Sometimes things will go wrong at work. Your demeanor and response to the situation sets the tone for the rest of the team. Mistakes are rarely catastrophic or career ending — don’t let your response to the situation indicate otherwise.

Actively Think About Career Progression and Succession Planning for Your Direct Reports

You’re now responsible for helping to shape the careers of your direct reports, in addition to managing your own career.

Many new managers ignore (or are unaware of) this responsibility. It’s often because their own managers didn’t have conversations with them about navigating their career, and therefore they have no reference point or framework within which to have this conversation with their own direct reports.

This can also be difficult if you haven’t put in the work to do some medium-term planning (at the very least) for your own career.

Any thinking around career growth should also include thinking about succession planning — i.e., if a direct report were to get promoted, move to a different team, or leave the company, do you already have someone prepared to take over their responsibilities? This is something too few managers actively plan for, and it’s usually because they don’t know how to approach the topic.

Two books I personally found useful — that helped me build a framework to have these conversations — are:

1. “The Manager’s Path” by Camille Fournier

2. “An Elegant Puzzle: Systems of Engineering Management” by Will Larson

Come Prepared for Your 1-on-1 Conversations

On the more general topic of 1-on-1 conversations, the most important advice I can offer is: Don’t show up unprepared!

• Start by making sure there’s a recurring meeting

• Don’t make cancellations/rescheduling a frequent habit. As a rule of thumb, I’ll never cancel successive 1-on-1 meetings.

• Make the time before the meeting to think about any discussion points you want to bring up, and encourage your direct reports to do the same

• Make the 1-on-1 about the whole person — i.e., in addition to discussing work and career issues, use the time to also understand how your direct report is doing outside of work. Take interest in their lives, and get to know them better.

• Use this time and space to offer both appreciation and course-correcting feedback. As an employee, there are few things worse than having a manager who only focuses on areas of improvement or who waits until the end-of-the-year performance review to offer any critical feedback.

• Don’t make the meeting only about giving feedback, but ask specific questions that elicit feedback for yourself too! Try not to make it just a “How am I doing?” but more like: “That cross-team project meeting I ran last week felt a little chaotic. What do you think I could have done better to produce a more organized meeting?”

Make the Time to Think About and Develop Your Craft

As an individual contributor, you’ve spent years honing your technical skills. If you were very intentional about developing your craft as a software engineer, shouldn’t you do the same as a manager?

Important skills to develop include:

• Holding great 1-on-1s

• Learning to coach

• Using the right leadership tactics depending on the situation (situational leadership)

• Connecting with your peers, both within and outside your organization, to continuously evolve as a manager

• Investing in the time to digest podcasts/books/blog posts about engineering-management situations and principles

• Building the mental muscles to zoom in on the details of technical work or zoom out to see the big picture when necessary

The Ability to Ask for Help Is a Job Requirement

A lot of things I’ve mentioned above — 1–1 discussions, career planning, becoming a better coach, having difficult conversations, figuring out how to focus on your top priorities, etc .— will likely be new to you! And yet, people think of their elevation into management as a sign they should have all the answers or know enough to not need any assistance.

This couldn’t be further from the truth. Knowing when to ask for help may be one of the most important skills you develop in this role, and you shouldn’t think you’re somehow a lesser leader because you need to lean on others.

Conclusion

Paraphrasing Andy Grove of Intel fame:

Managers are the muscle and bone of an organization.

Your role is critical to the success of the organization, and it’s important for you to make the time to discover and understand it well so you can put your best foot forward.

You’re, in effect, a mini-CEO of your own suborganization within the company. Bringing both mindfulness and intent to the role is critical to the team’s success — and ultimately to your success.

Thanks for reading!

References

1. “The Manager’s Path” by Camille Fournier

2. “An Elegant Puzzle: Systems of Engineering Management” by Will Larson

3. About Andy Grove

4. “High Output Management” by Andy Grove

As the news of the executive order on H-1B visas broke a few days ago, as a former H-1B visa holder, I reflected on why I left the US almost two years ago. This post is a reflection of my time spent in the US: As a dependent of an H-1B visa holder (H4), as an international student (F1), and then as a professional (H-1B).

First Contact

A little history (and an interesting anecdote): My dad was also a H1B holder in the IT industry. When I was 8 years old, we moved to Fremont, California from New Delhi, India in the spring of 1992. We returned shortly after in the summer of 1993. My mom, sister and I were on a H4 visa as his dependents at the time.

In that relatively short time, my sister and I went to public school in Fremont, we made friends, and traveled the country with my parents (California, Nevada, Michigan and New York).

Even at the age of 8, it felt like this move abroad had dramatically increased the size of the world in my mind. Moving to a new country, to a new home, going to a new school, meeting people who looked very different from me, and having a million other new experiences felt daunting at times, but it mostly felt like an adventure.

That year-and-a-half felt both infinitely long, and fleetingly short. The memories are etched in my mind in rich detail.

And then, just when it felt like we were starting to find our rhythm, we left and moved back to India. The transition back to the Indian school system was gruelingly difficult. For starters, the K1–8 curriculum in the US is substantially easier than the equivalent curriculum in India. While this made the transition from India to the US extremely easy, the transition back was a nightmare, because I had missed the entire Indian grade 3 curriculum, and was playing catch-up through most of grade 4 and 5.

I also had to re-learn reading and writing Hindi. Almost 2 years of no practice reading and writing it at that age, meant I had forgotten it. On top of catching up in general, having to re-learn a language was a recipe for months of tear-filled evenings and after-school work.

For my sister in Grade 8, this transition was even harder.

Returning for Graduate School

In 2006, I arrived back in the US after 13 years, on an F1 (student) visa to pursue a Masters Degree in Electrical Engineering at the University of Michigan, Ann Arbor.

Tuition fees as an international student at the University of Michigan weren’t cheap: $32,000 a year. While I did have admission offers from 3 other US universities, none of them were substantially cheaper. With Michigan being a top school, I wanted to challenge myself by studying with some of the brightest students from around the world.

And so the choice was made.

My father paid for my first semester through a bank loan with our house as guaranty. My second semester was paid for with a private loan in the US, for which I had a US citizen co-signer, an ex-colleague of my dad (to whom I will forever be grateful).

When the house your parents own is on the line, AND you’re on the hook yourself for the largest amount of money you’ve ever owed anyone, it lights a fire under you. I wasn’t even sure where the tuition money for the third semester was going to come from.

Also, while the bank loan took care of tuition expenses, I was on my own for living expenses, so I took on the full 20 hours of work a week that international students are allowed, to pay for my rent, groceries, utilities etc.

To meet the 30 credit requirement for graduation, I took 12 credits my first semester, and 17 (SEVENTEEN) credits my second semester. In retrospect, the winter of 2007 was a time where I experienced the lowest of lows, and the most exhilarating highs.

Finding a Job

In my second semester at school, I landed a co-op at, what I considered, my dream company — MathWorks. I had used MathWorks tools like MATLAB, Simulink and Stateflow throughout my coursework and labs during my graduate program, and loved how they opened up the world of scientific computation and analysis.

I doubt anyone at MathWorks ever knew how much this job offer meant to me. I needed a paid co-op to start repaying student loans.

With my second semester done, In the early summer of 2007, I moved from Ann Arbor, Michigan to Natick, Massachusetts — a suburb of Boston, to start out as an co-op at MathWorks. I was able to do this thanks to Curricular Practical Training, CPT for short (Similar to Optional Practical Training — OPT which is available after you graduate).

I had the role of an “Application Support Engineer”, working with MathWorks customers via phone / email, helping them solve complex problems and debug issues as they used MathWorks tools to build complex visualization tools, software for embedded systems, complex simulations etc.

Why was an “Electrical Engineering” graduate student doing tech support? Because:

1. I saw it as a way to connect with some amazing scientists and engineers, and getting a glimpse of the amazing things they were bringing to life

2. It was a way for me to get my foot in the door to a company I admired

3. The tools I was using, and helping customers use, were directly relevant to my coursework at school.

4. I didn’t know it at the time, but in hindsight, starting out in technical support was one of the best things for my career. It taught me to look at problems and software in a way that was very user-centered, building empathy for our customers.

3 months into my 6 month co-op, I got a full-time job offer starting in January 2008. With just 1 credit left to graduate, I took an online course at the University of Illinois at Urbana-Champaign over the fall of 2007 while I was still in Boston at my co-op, and transferred the credits back to Michigan to graduate in December 2007.

The timing of it all was sheer luck. I qualified to apply for the H-1B visa for 2008, and was lucky to get the visa in my first try. (My understanding is that most international graduate students follow the path of CPT -> OPT -> H-1B).

And then… the recession hit.

Wading Through the Recession

I had made it into MathWorks just in time. There was a hiring freeze that lasted close to 2 years, and if I had graduated a semester later, I likely would not have had the same job offer waiting for me.

I also got married in 2008, and my wife (also an engineer by profession) left her job in India and arrived back with me to Boston. She was on a H4 visa, incredibly restrictive at the time, but we knew what we were getting into.

She tried to search for a job, and for a year the calls would come, but prospective employers would suddenly disappear when they found out they’d need to sponsor a visa. In the midst of a recession, it’s understandably hard for small and mid-sized businesses to afford hiring people who need H1B visas. The cost of the process, especially with attorneys involved, is expensive.

With the economic recovery in the US struggling to take hold, things weren’t looking like they’d pick up soon. She had always wanted to go to grad school and get an MBA, so she began her pursuit to get into grad school.

The Road to Permanent Residence

A little more than two years into my role in Technical Support, and after a few internal projects with other teams within the company, I switched to being a Software Engineer full time. This was in 2010. I began my career working on an amazing software product called Stateflow.

Towards the end of 2011, my employer decided to apply for an employment based green card for me. Since I had a Masters degree and some prior work experience, that put me squarely in the EB2 category of green cards. For those of you who don’t know, EB stands for Employment Based. At some point in the process, once the initial petition is approved, you are given a priority date, which effectively says “get in line”.

The priority date is interesting because USCIS publishes a visa bulletin periodically that informs the public what priority dates are being processed, depending on your nationality and your Green Card petition category. A fun fact about priority dates is that the USCIS status on them can “regress”. What does this mean? USCIS could publish a bulletin saying that they are processing all applications with priority date up to April 2011, and then a few weeks later, they could publish another bulletin that pegs the priority date to June 2006.

It was only at this stage that I started digging into the process some more to understand the different factors at play that might influence the priority date. Research aside, it became evident very soon that the wait for a green card in the EB2 category, for an Indian national like me, was going to take a very long time. How long you ask? 54 years according to a recent estimate:

Living in Immigration Limbo

As I watched the wait times increase, with no end in sight, I remained naively hopeful that a sudden policy change would bring relief. I tried not to think too much about it, and kept doing my best at work.

I worked hard, because (especially) as an engineer on a H-1B, there’s no room to become complacent or sloppy. If you lose your job for any reason, you have 60 days to find an equivalent job, or leave the country.

We really wanted our life in the US to work, we wanted to settle down there. I put my head down and gave it my best. Some of that work led to 2 US and 1 international patents.

In 2014, we continued hoping, and we bought a house.

In 2016, my daughter was born. We kept building our professional network and made friends. We thought we were really putting down roots.

Between 2010 and 2018, I kept advancing in my career, becoming a Senior Software Engineer, and then a Software Engineering Team Lead.

As the years went by, the wait times kept increasing.

All this time, I realized how much of a pain the H-1B really was:

• Since H-1B visas are valid for 3 year stretches at the most, and with my wife and I both on a H1-B by 2012, every year or two when we traveled out of the country, we’d realize that paperwork for visa renewal would be necessary because one of our visas would have expired. Oh, and it’s generally “discouraged” to apply for a visa renewal anywhere other than your home country.

• Say you want to switch careers i.e. you’re a software developer, but you’ve developed a passion for product management, or marketing — you need to tread carefully, particularly if you’re in the Green Card queue. A H-1B transfer isn’t guaranteed, and you may lose your place in the “queue”, having to go through the Green Card process again, because you’re in a new role.

• Even if you don’t switch roles, or companies, your H1-B renewal isn’t guaranteed anymore, particularly since Trump took office in 2016.

• When returning to the US after a holiday, or a visit to your home country, the CBP (Customs and Border Patrol) officers at airports will look at your stamped visa and be unpleasant jerks. Once, an officer almost denied me entry after a 17 hour flight, because even though I had a valid visa stamped on my passport, I wasn’t carrying my I-797 notice of approval document with me. In the 4 visits back to the US before, no CBP officer had ever asked me for that document. I’ve heard stories of CBP officers asking software engineers questions about programming off wikipedia to verify that the engineer is really a software engineer. 🤦‍♂

• Unfortunately, the H-1B visa is sometimes abused (some Indian IT cos come to mind). Also unfortunately, as a H-1B holder working for a company paying you really well, you will get lumped in with the H-1B abusers and be accused of stealing jobs, working for low wages and displacing American workers.

• The Green Card queue has a per-country quota. It’s not fair or unfair. It is what it is, and it’s not great for you if you’re an Indian national. The fact that you’ve contributed major tax dollars into social security and medicare (that you likely won’t ever see a dime of) and have been a law-abiding citizen mean nothing.

The Choice

“In any moment of decision, the best thing you can do is the right thing. The worst thing you can do is nothing.”
― Theodore Roosevelt

A year into the Trump presidency, we thought we had seen enough. After a decade, it seemed like only a fool’s hope to assume that things would get better.

The choice was simple, we either

• Stay and face all the issues I’ve mentioned above, or

• Exercise the privilege and resources that we have to move somewhere else, where we’ll be free, while still maintaining or improving the quality of life that we had become accustomed to.

Free to travel without being harassed about our visa status.

Free to take on the roles and jobs we’re passionate about, even if it means taking risks in new roles, or at very small companies.

Free of accusations of being a wage undercutting job stealer.

Free of the deluge of immigration paperwork that always seemed to be coming our way, to continue to stay in the US legally.

We chose to leave the US. We chose freedom.

The Promise of A New Life

We had heard about Canada’s Express Entry program, that granted permanent residence to applicants with the right mix of job skills, language ability, and work experience.

It sounded promising in theory, but we wanted to be sure we’d like our potential new home. In the summer of 2017, we visited the city of Toronto in Canada to get a feel for the city.

We picked Toronto because, with the high density of opportunities in the Software and Services industry, we wanted to give ourselves the best chance of landing on our feet in a new country, where we had no relatives, and very few friends or professional connections.

Exploring the city over many days, we enjoyed the energy and diversity we saw, and our minds were made up.

Tasting Freedom 🇨🇦

We kick-started our application for Express Entry in earnest. The process was surprisingly simple and transparent. We didn’t need to hire any immigration attorneys, or consultants. It was all self-serve, although it did require us to be thorough in the documentation that we collected.

The best part was, after being invited to apply for permanent residence, we submitted our application on December 5th 2017, and on December 21st, we had confirmation that we were permanent residents!

Years of waiting in Limbo in the US vs. 16 days. Sixteen DAYS.

Fast-forward to the fall of 2018, and we sold our home in Newton, Massachusetts and permanently moved north, across the border to Canada.

Almost two years later, we feel very well settled in our new life here. The few experiences we’ve already had traveling out of the country and returning back home to Canada as permanent residents have been a joy. There’s so much I want to talk about in our experience of moving to Canada, but I’ll save that for another post.

This isn’t a book review! I just want to make that clear to begin with. 🙅‍♂📕 Nor is it a book summary. Well, not exactly!

Instead, I want to use this space to capture some of the insights from “the fearless organization” by Amy Edmondson.

Insights can be personal and subjective (what is insightful to me, may not be insightful for you). 🔎

Even so, a fair amount of information in the book included the kind of stuff I had never run into before, and I hope you will find it useful too.

Some of the information is distilled out from the book, some of it is paraphrasing sections of the book. 🔖

About the book

“The fearless organization” was written by Amy Edmondson — currently (As of April 2020) the Novartis Professor of Leadership at Harvard Business School.

From the book description: “The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth offers practical guidance for teams and organizations who are serious about success in the modern economy. … This book explores this culture of psychological safety, and provides a blueprint for bringing it to life.

What Psychological safety is NOT ⚔️

“Psychological safety is not about trust, lowering performance standards, or even a complete absence of fear”

Since the book focuses on psychological safety, it’s very important to understand what psychological safety is NOT:

1. Another word for trust. Psychological safety is experienced at a group level. Trust – usually between two entities. Psychological safety is usually a temporally immediate experience, trust is an expectation about whether or not the other party can be counted on.

2. About “lowering performance standards”. Wanting to create an environment that is psychologically safe does not imply that people should no longer hold each other accountable.

3. About the absence of fear. There may be fear present in an organization around long term prospects, ongoing emergencies, anxiety about some endemic issue etc. Individuals may be worried about their performance. Despite all of this, if people are able to engage in constructive dialogue with candour and authenticity, then they are feeling psychologically safe.

4. A personality trait. Psychological safety is the level of inter-personal risk that people in a group anticipate, or experience i.e. it is very much an experience that plays out between different people, and not an innate personality trait.

What psychological safety does, and a leaders role in helping to establish it

Amy Edmondson’s draws an interesting analogy between operating a car and “team dynamics”, to describe the role of psychological safety.

Leaders must carefully use the right amount of fuel / throttle 🚀 and braking 🛑 to ensure the car runs well.

Leaders need to:

• 🛑 Remove the brakes by building psychological safety to spur learning and avoid preventable failures.

• 🚀 Set high standards, inspire, and enable people to reach them.

• 🚀 Share, sharpen and continually emphasize a worthy purpose.

Why do people fear speaking up to ask questions / raise concerns

In situations where a person might speak up, but chooses not to, two most frequently mentioned reasons are:

• Fear of being viewed / labeled negatively.

• Fear of damaging work relationships.

On this note, one of my favourite parts of the book was the introduction of the notion of the “Asymmetry of voice and silence”: 🗣 🙊

• Voice 🗣 is effortful and might (but might not) make a real difference in a crucial moment. Most of the time, the potential benefit will take a while to materialize, and might not happen at all.

• Silence 🙊 is instinctive and safe. It offers self-protection benefits, and these are both immediate and certain.

Unfortunately, since not offering an idea is an invisible act, it is hard to encourage the expression of that idea, and engage in real-time course correction.

In other words, when an opportunity to speak up arrives, there is a cost-benefit analysis running in our minds, weighing the costs and benefits of speaking up.

Due to the asymmetry of voice and silence, benefits are unclear and delayed, costs may be immediate and tangible, and so this cost-benefit analysis always overweights silence.

The two broad sets of learning behaviours in organizations

• Learn-what: independent activities like learning about the latest best practices and new developments in your profession. 📚

• Learn-How: Team-based learning that includes sharing knowledge, offering suggestions, and brainstorming better approaches. 💭

Psychological safety results in an uptick in Learn-How behaviours, because people feel like they are in an environment where they are able to overcome interpersonal risk to engage in more “Learn-How” behaviours.

Confidence vs. feeling psychologically safe 👷

The more confident people were in their knowledge, the more they tend to speak up / raise concerns / ask questions. However, since the merit of an idea and confidence are independent variables — just because a person confidently says something, does not necessarily mean the idea / question / concern has merit — establishing psychological safety is important for facilitating knowledge sharing, and getting a spectrum of ideas.

That is, we want to create an environment where even those with lower confidence levels can speak up, because it feels safe for them to do so.

Interestingly, the frequency of communication among co-workers also led to psychological safety. The more we talk to each other, the more comfortable we become doing so.

The dynamics of effective teams

Project Aristotle (at Google) found that even the smartest / high-powered engineers at google needed psychological safety to operate, and contribute their talents. Four other factors explain team performance:

• Clear goals 🥅

• Dependable colleagues 🤓

• Personally meaningful work 🌄

• A belief that their work has an impact ⚒

But psychological safety was found to be the most important. Psychological safety is associated with higher work engagement, mental health, and lower turnover.

Fear of failure, and it’s effect on learning and innovation 👩‍🔬

Success requires constant innovation, fuelled by expertise, ingenuity, and teamwork. Without psychological safety, it is difficult for any of those to be put to good use.

• Without the freedom to fail, people will seek to repeat something safe, that’s been good enough in the past. Their work will be derivative, not innovative. Experimentation, and the inevitable trial and error process are necessary to innovate. 👨‍🔬

• From Astro Teller of GoogleX: “The only way to get people to work on big, risky and audacious ideas, and have them run at the all the hardest parts of the problem first, is to make that the path of least resistance, and show them that it’s OK to fail. 💪 It’s natural to fear what other people might think, and about losing our job. That’s why, unless a leader expressly and actively makes it psychologically safe to do so, people will seek to avoid failure.” 😰

• From Carol Dweck and her work on the Growth Mindset: “When people believe their performance is an indication of their ability or intelligence, they are less likely to take risks, for fear of a result that would disconfirm their ability. But, when people believe that performance reflects effort and good strategy, they are eager to try new things and willing to persevere despite adversity and failure.” 🏋

Summary

I took a lot away from reading this book. There were some fantastic nuggets of information to be found🥇. The book gave me the tools to identify low levels of psychological safety, and tools to improve it in a group.

The book does an amazing job of driving home the consequences of neglecting psychological safety within a group, and the benefits to be gained from putting in the work to build a culture of safety and comfort around speaking up.

I hope you get a chance to read it and enjoy it too.

Macros and Attributes abound in Rust, and it’s often useful (nay, important!) to know how they are morphing your source code. This knowledge is important to help you:

1. Gain a deeper understanding of what your code is doing.

2. Debug your source code more easily and effectively, when using a macro or attribute produces unexpected results.

cargo-expand is a useful cargo sub-command that can be installed and run to “expand” the macros and attributes (hereafter, collectively referred to as “code shortcuts”) in your source code, and show you the code being generated.

Let’s say you start with the following code, where we have a simple struct called PersonDetails, and we want this type to be printable.

The code looks like this:

<a href="https://medium.com/media/b208c68346a222b650025a7b227dbc76/href">https://medium.com/media/b208c68346a222b650025a7b227dbc76/href</a>

I’ve made PersonDetails printable by using the Derive attribute to derive from the fmt::Debug trait.

But how exactly is the use of this attribute with the fmt::Debug trait making the Struct printable?

As it turns out, you can expand the attribute and look at the generated code using the rust compiler.

Unfortunately:

1. The rustc command needed to expand code shortcuts requires you to first install and then switch manually to the rust nightly toolchain.

2. The generated code is printed to the terminal, with formatting that isn’t ideal, and without syntax highlighting.

3. You’ll need to switch back to the non-nightly version of the toolchain once you’re done.

At my project root, I need to run:

rustup override set nightly

then:

cargo rustc —-profile=check -- -Zunstable-options --pretty=expanded

producing the following result:

You’ll see that the formatting is janky in places, especially within the main function.

Let’s try the same thing with cargo-expand.

cargo install cargo-expand

cargo-expand will use the rustfmt tool if it is installed on your system to format / prettify the generated code.

You can run cargo expand even without rustfmt installed. To install rustfmt run:

rustup component add rustfmt

While cargo-expand also uses the nightly build of the rust behind the scenes, it doesn’t expect you to manually change the default toolchain of the project you’re working in.

Expanding the code shortcuts on the same example with cargo-expand produces:

Observe that:

1. The output makes better use of whitespace when formatting. ✨

2. The output is syntax highlighted! 🎉

Go forth, explore, and try cargo expand on code containing other macros such as vec! or with some of these super-useful attributes.

References

cargo-expand: https://github.com/dtolnay/cargo-expand

rustup: https://rustup.rs/

rustfmt: https://github.com/rust-lang/rustfmt

Macros: https://doc.rust-lang.org/1.7.0/book/macros.html

Attributes: https://doc.rust-lang.org/reference/attributes.html

6 useful Rust macros that you may not have seen before: https://blog.usejournal.com/6-useful-rust-macros-that-you-might-not-have-seen-before-59d1386f7bc5

We had a year-end hackathon here at Prodigy Education. Over the last two days of 2019, teams and individuals got together to bring their ideas to life.

For fun.

To learn something new.

Or maybe to prove out a concept or idea.

I had been passively consuming information and code snippets about Rust for the past few weeks and thought the hackathon was the perfect opportunity to get hands-on with the language.

The time-constrained nature of the hackathon forced me to move and learn quickly, while also solving a real-world problem.

Why Rust?

I’ve spent eight of my first 10 years as a software professional using C and C++.

On a positive note, I’ve loved the clarity a language like C++ can offer in terms of static typing and the compiler catching errors early.

My personal opinion of C++ is that it:

• Easily allows engineers to shoot themselves in the foot

• As a language, has become quite bloated and complex, in my opinion

• Lacked good/standard/widely adopted package management

Since my move to building web applications, I’ve worked exclusively with Python and JavaScript, using frameworks like Django, Flask, and Express.

My experience so far with modern web application development stacks in Python and JavaScript is they offer good application iteration and delivery speed but can be CPU and memory intensive, sometimes even when idle.

I do often find myself missing the type safety, speed, and leanness of a (well-written) compiled C++ application.

I wanted to explore what web-application development might look like with a lean, bare-metal programming language like Rust.

No runtimes. No garbage collection. Just a binary loaded and run by the kernel.

The Goal

The goal was to build an application with a Rust back end and a JavaScript + React front end to display the contents of an S3 bucket as an image gallery. Users would be able to:

• Browse all the images in the bucket (pagination optional)

• Upload images

• Add tags to the image during upload

• Search and filter by file name or tags

All fun hackathon projects need a name, so I decided to call this one:

RustIC -> Rust + Image Contents

I’d consider the hackathon a personal success if I walked away with (in descending order of priority):

• A basic understanding of Rust, its type system, and memory model

• Exploring S3 functionality with respect to presigned links for files and arbitrary tags

• A functioning proof-of-concept application

Since my emphasis was on delivering functionality while balancing that with learning, a lot of the code I wrote necessarily leaned toward being functional — i.e., code organization and efficiency were secondary concerns.

Principles of Rust

Before I began, I was curious to learn the principles the language designers had in mind when creating this new language. I found an abridged (albeit dated) version and a more detailed one.

Contrary to what I read on a lot of blogs, it is possible to have memory leaks (through improperly setup reference cycles) and perform unsafe operations (in an unsafe block) in Rust. As mentioned in the detailed Rust FAQ,

“We [the language creators] do not intend [for Rust] to be 100% static, 100% safe, 100% reflective.”

Getting Started on the Back End

A Google search for “Rust web framework” yielded a top hit for Rocket. I dove into the site to find the documentation and examples seem well laid out and thorough.

One caveat with Rocket is it needs the nightly version of Rust to operate. Not a big deal in th context of a hackathon.

The GitHub repo has plenty of examples. Perfect.

I used Cargo to set up a new project, added Rocket as a dependency in the TOML file, and following the instructions in the Getting Started guide for Rocket, set up a route:

#[get("/")]
fn index() -> &'static str {
    "Hello, world!"
}

fn main() {
    rocket::ignite().mount("/", routes![index]).launch();
}

For anyone familiar with Django, Flask, Express etc., this should look very readable. As a Rocket user, you use macros as decorators on functions to map a route to a handler function.

At compile time, the macros are expanded. This will be completely transparent to you. If you’re curious to look at the expanded code, the cargo-expand crate can be leveraged.

Here are the interesting/challenging highlights of my app-building experience with Rust:

Specifying the route response

I wanted my contents route to list all the files in the S3 bucket by returning a JSON data structure.

Notice (in the code below) how you can look at the function handler associated with the route to immediately determine the response shape.

Crafting the response shape was extremely easy. If you think of the JSON data as a structure with fields, where each of those fields could, in turn, contain its own structure and fields, then this maps well to a Rust struct.

So all you have to do is to define the struct(s) that constitute the response data shape and tag each one with:

#[derive(Serialize)]

struct(s) tagged with #[derive(Serialize)] can be passed to the JSON function from rocket_contrib::json::Json, and away we go!

<a href="https://medium.com/media/88b1f727e5162dbec5fdbe12ae0fd4a3/href">https://medium.com/media/88b1f727e5162dbec5fdbe12ae0fd4a3/href</a>

Working with multipart uploads

I was knee-deep in building the application with Rocket when I realized I’d likely have a form on the front end that’d result in a POST with multipart/form-data.

Unfortunately, Rocket (as of v0.4) doesn’t have multipart support. This seems to be scheduled for v0.5.

This meant having to work with the multipart crate and needing to figure out integration with Rocket. The resulting code worked but could’ve been a lot cleaner with in-built multipart support in Rocket.

<a href="https://medium.com/media/8b9a7516f14a22786947abfd1b5cfc94/href">https://medium.com/media/8b9a7516f14a22786947abfd1b5cfc94/href</a>

Configuring CORS

Once the routes were in place and I’d done some testing using curl and Postman, it was time to integrate with the front end. I needed to set the response headers appropriately to avoid CORS issues.

Again, there’s no in-built support in Rocket.

Looking through the issue log on the GitHub repo, I saw some of the building blocks for a solution, which resulted in this:

<a href="https://medium.com/media/41ac2d5f9106a49375ec1a0c215f5985/href">https://medium.com/media/41ac2d5f9106a49375ec1a0c215f5985/href</a>

Shortly afterward, I discovered rocket_cors, which significantly slimmed things down.

<a href="https://medium.com/media/6919e30bbd77f905a42e3c632d1cb18c/href">https://medium.com/media/6919e30bbd77f905a42e3c632d1cb18c/href</a>

Up and running

A simple cargo run invocation in the terminal spits out this beautiful output:

The Activity Monitor on my machine is telling me this app is humming along, taking just 2.7MB of memory.

And that’s the unoptimized debug version.

The same app built with the — release flag sips 1.6MB of memory.

With the Rust-based back end service up, hitting a /contents route on the service produces:

<a href="https://medium.com/media/d9210e75df00f46d9c5020727805bf4f/href">https://medium.com/media/d9210e75df00f46d9c5020727805bf4f/href</a>

On the front end, the work was relatively simple. Using:

• React

• React Bootstrap

• react-grid-gallery

• react-tags-input

The user sees a page where they can browse images and search/filter by file name or tags.

The user can drag and drop to upload files and has the ability to tag files before they’re submitted for upload.

What I Loved About Building an App With Rust

• Cargo, especially for dependency and application management, is amazing

• The compiler is extremely helpful for compiler errors. Check out this blog post where the author uses the errors from the compiler to guide him toward the right solution. My experience definitely mirrored this.

• I was pleasantly surprised by the availability of crates for every piece of functionality I needed.
  ○ Web frameworks? Check.
  ○ Middleware options for the web framework? Check.
  ○ S3 and other AWS service client libraries? A Redis client library? JSON serialization and deserialization? Check, check, and check!

• The online Rust Playground, where I could experiment with small code snippets

• The Rust language server, which integrated nicely into Visual Studio Code, and is meant to be front-end agnostic, providing live error checking, formatting, symbol lookup, etc. I was able to experiment and make progress for hours without building.

Inconveniences, Surprises, and Troubles

Although Rust documentation itself is fantastic, the documentation for some of the crates I had to depend on left a lot to be desired — particularly around usage examples.

Some crates had well written integration tests, which offered clues on usage. As always, Stack Overflow and Reddit helped.

In addition:

• Understanding ownership, lifetimes, and borrowing can produce a steep learning curve initially, especially when pushing to deliver functionality over a two-day hackathon. With a little poking, I could draw parallels with C++ and figure things out, but I still found myself scratching my head at times.

• Of all the things, Strings tripped me up for a few minutes. String vs. &str was confusing — until I took the time to understand ownership, lifetimes, and borrowing. Then, it all makes sense.

Other Observations About the Language

• There’s no real null type in safe Rust (although there’s a notion of a null raw pointer). What you’ll typically see is the liberal use of Option types. which may evaluate to Some or None, with pattern matching frequently coming into play.

• Pattern matching is awesome. It’s one of my favorite features in Scala, and I love that Rust has it too. The code looks expressive and allows the compiler to flag unhandled cases.

<a href="https://medium.com/media/494bd7088bb2efbb89ef00d0882e875f/href">https://medium.com/media/494bd7088bb2efbb89ef00d0882e875f/href</a>

• Speaking of safe and unsafe, you can still do lower-level programming, for say, interfacing with languages like C using unsafe blocks of code. While a lot of correctness checks don’t go away, you’re allowed to do things like dereference raw pointers within unsafe blocks. Seeing an unsafe block is informative for anyone reading the code, too.

• Allocation on the heap is done via Box, as opposed to using new and delete. This feels strange at first but is easy to get used to. There are also other smart pointer options in the standard library if you need to do, say, reference counting or you need to hold onto weak references.

• Exceptions are interesting in Rust, in that it doesn’t have any. Your options are either a Result<T, E> for recoverable errors or using the panic! macro to signal an unrecoverable error.

<a href="https://medium.com/media/2d8fe06f475991e1201ce0f90e6aa759/href">https://medium.com/media/2d8fe06f475991e1201ce0f90e6aa759/href</a>

The guide states:

“In many cases, Rust requires you to acknowledge the possibility of an error and take some action before your code will compile. This requirement makes your program more robust by ensuring that you’ll discover errors and handle them appropriately before you’ve deployed your code to production!”

Key Takeaways and Lessons

• John Carmack once described the feeling of writing Rust code as “very wholesome.” I’d agree with that sentiment. This hackathon felt a lot more like opening doors to constantly discover and learn new things, rather than an indiscriminate code-cobbling effort.

• In hindsight, I should’ve chosen my web framework a little more carefully. With a little more thought, I may have gone a different route (no pun intended). Web framework options are discussed and compared here. I may consider iron, actix-web, or even tiny-http for my next project.

• I’ve only scratched the surface as far as truly learning Rust goes — a 16-hour hackathon does not make a Rustacean, although my efforts here have got me curious to dig a lot deeper into the language. I’m excited for the future of Rust. I think it brings a lot of discipline to application building, is a very powerful and expressive language, and already offers runtime speed and memory performance on par with C++.

Thank you for reading, I hope you learned something new about Rust or Rocket. Happy hacking!

Resources

RustIC back-end code

RustIC front-end code

Rust FAQ

The Rocket web framework for Rust

Rusoto: An AWS SDK for Rust

The Engineering team at Prodigy believes in using the right tool for the right job. We actively use Javascript, Python and Ruby, and are always willing to experiment with new technologies if we see a compelling use case.

The views and opinions expressed in this post are those of the author and don’t necessarily reflect the view of Prodigy Education or the engineering organization within Prodigy Education.

This post was originally published on January 10th, 2020 on the Better Programming publication.

Learning To Use Rust Over a 16-Hour Hackathon was originally published in Prodigy Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Do you invest in the stock market?

If so, what are the principles you apply when deciding how to invest your hard earned money?

Do you:

1. Look exclusively at past performance?

2. Follow your close circle of friends, and invest in the same things?

3. Follow the market? You trust the masses, most of them are probably right… right?

4. Not see the need to invest? You have enough money for your current expenses, and the money you are saving in a low interest account is good enough. But what about the falling purchasing power of that capital over time?

5. Carefully research company fundamentals, look at the price-equity ratio, consider future direction etc., assuming you either have some knowledge of the domain, or rely on trusted experts who do?

6. Look at broad social, economic and industrial trends, spot areas of promise, and find investments that fit these areas?

If you’ve ever had money to invest, you’ve given this some thought (hopefully).

Now let me ask you this:

Have you given as much thought to your knowledge and skill investments, as your monetary investments?

If you’re a Software Engineer like me, you are a knowledge worker. You invest your time, energy and money acquiring knowledge. You expect these knowledge investments will pay dividends, and increase your value to the market (Aside from the satisfaction of constant growth from learning).

Look back at the 6 broad strategies above, they’re all equally applicable to making knowledge investment choices.

What has your strategy been? What are some of the areas you’ll want to invest in over the next few years?

Here are some of the big trends I anticipate. Emphasis on some, because I won’t call out the ones that seem obvious to me (e.g. Artificial Intelligence) or ones I am not personally interested in investing in right now.

The rise of the socially and environmentally conscious engineer

The standout challenges of the coming decade will likely be in the areas of

• Clean energy tech

• Economic empowerment and social mobility

• Equal access to quality education

• Food technology for a growing population and,

• Health technology for an ageing one

All while building products and services that have a low environmental impact.

It’s going to be a unique time in the short history of software engineers, as we have the opportunity to engage in deeply meaningful and valuable work, and a responsibility to be a defining force for good in all of these areas.

Actions for Impact:

1. As of December 2019, Angellist shows 250+ startups in clean energy tech, and 1400+ startups in education tech. And those are just the startups! Have you explored their mission and vision? What about the other areas mentioned above?

2. As a software engineer, have you thought about the role you can play in the climate crisis? The energy crisis? Or helping to level the playing field for those vastly less fortunate than you?

3. What diverse sources of information can you tap, to educate yourself about global issues and the ways in which some people / organizations are tackling the problem?

A demand-supply tension for systems programmers

Hundreds of millions of devices are online with more coming online every second. We know this as the Internet of Things (IoT).

5G is almost here, which means a lot of these devices, now and in the future, won’t be constrained to a WiFi connection to talk to each other.

This is going to further enable

• Robotics (everything from drones, to warehouse bots)

• Autonomous systems

• Augmented reality systems

• Data gathering and transmitting sensors etc.

We’ll all be living on the “edge”. (Sorry, I couldn’t resist!).

The complexity of “edge” devices is dramatically scaling up with every passing year. I expect this to lead to a spike in demand for Systems engineers and programmers.

On the supply side, we have numerous issues:

1. Formal computer science course enrollment seems to be dropping year-over-year, all the way from secondary school to college, at least in the US.

2. I suspect languages like Python and Javascript are becoming the lingua franca of programming courses, with an increased emphasis on application building, and a reduced emphasis on deep computer science concepts.

The silver lining here is that a lot more children are being exposed to robotics and hardware-software interfaces through school, or coding / robotics camps.

I should add that a lot of systems programming, particularly for complex applications (think industries like industrial automation, automotive and aerospace) is also done via “Model-Based Design”. High-level block diagrams created in software result in auto-generated code for embedded devices.

Even here, having a solid knowledge of low-level programming languages and hardware fundamental is inescapable.

Actions for impact:

1. Learn a systems / low-level programming language like C or C++, or a more modern systems programming language like Rust.

2. Work towards building an awareness of low-level / deeper computer science concepts. You don’t necessarily need a computer science degree for this.

3. Buy an Arduino, or maybe a Raspberry Pi. Understand the hardware-software interface, make a few LEDs light up, then do something bigger and cooler.

4. Learn about Model-Based Design, and explore some tools that allow you to model your system and generate code from the model.

Full Disclosure: Model-Based Design Tools like Simulink and Stateflow are close to my heart, since I spent a good chunk of my early career on Stateflow development.

Emotional Intelligence in an era of low empathy

My last suggestion is not a tech-skill, but a collection of soft-skills. The term “soft-skills” doesn’t do it justice. I’m referring to Emotional Intelligence and everything it signifies, such as excellent communication, the ability to have difficult but candid conversations, demonstrating grit, motivating others, being mindful of mental health etc.

All of these skills are only “soft” in that they are not as tangible as learning a technology. In reality, there’s nothing soft or easy about them.

Add to this the fact that we live in an era of low and divided attention spans, lower empathy and lower social interconnectedness.

Sadly, emotional intelligence runs the risk of becoming rare at a time when we need it the most.

Emotional Intelligence has always been necessary, but it’s especially important now as the decade brings an economy that is becoming increasingly knowledge based.

An economy that rewards innovation, creativity and working well with others. Exhibiting emotional intelligence is going to be a hard pre-requisite, as opposed to a “nice to have”.

Actions for impact:

1. How well do you truly know yourself? Have you taken something like a briggs-meyers personality assessment test to get a rough sense for how you operate in most scenarios? How self-aware are you?

2. The World Health Organization says that Depression is one of the leading causes of disability worldwide. What do you know about mental health in general? Do you know how to spot the signs of a mental health issue in yourself, or others? If you did, would you know how to intervene?

I recently finished reading Give and Take by Adam Grant [1]. It’s rare to find a book that gives you interesting insights, while also holding up a mirror for you to see yourself in a new light. This was one such book.

In essence, Give and Take describes three primary behaviour profiles:

1. Givers – Generously giving their time, energy and resources to help others succeed. In this category, there are also “Altruistic Givers” who often forego success by putting the needs of others before themselves, and “Otherish” givers who are equally motivated in finding their own success as they are in making others successful.

2. Matchers – Who believe strongly in reciprocity and only offering resources to those from whom they can expect something in return, and

3. Takers – Low on empathy towards others, their primary focus is their own success.

As expected, people don’t always neatly slot into these three buckets.

Reflecting on my past behaviour and actions, I can honestly say that I have found myself toggling between Giving and Matching over the years, and I was definitely in situations where I tended towards being a Taker early in my career.

To me, that was the biggest personal insight – Giving, Matching and Taking behaviours can be very situational.

Apart from an insight related to the primary focus of the book, I wanted to share some excerpts from this book that raised my awareness levels, particularly in the context of teams in a professional work environment.

Build Self-Awareness in Failure and Success

Generally speaking, it’s important to recognise that a lot of your success at work, comes with the support of others on your team. They are a part of your successes, just as you should be a part of theirs.

Adam Grant mentions a study (with professors Robert Huckman and Gary Pisano of Harvard Businss School) that wanted to discover whether surgeons get better with practice.

Overall, the surgeons didn’t get better with practice. They only got better at the specific hospital where they practised. For every procedure they handled at a given hospital, the risk of patient mortality dropped by 1 percent. But the risk of mortality stayed the same at other hospitals. The surgeons couldn’t take their performance with them. They weren’t getting better at performing coronary artery bypass grafts. They were becoming more familiar with particular nurses and anaesthesiologists, learning about their strengths and weaknesses, habits, and styles. This familiarity helped them avoid patient deaths, but it didn’t carry over to other hospitals. To reduce the risk of patient mortality, the surgeons needed relationships with specific surgical team members.

Your outcomes at work, especially your successes, are as much a function of your work environment and the team you work with, as they are a function of your own skill and attitude. This should not be used as a crutch or excuse in failure, and it absolutely should be kept in mind when achieving success on a team.

Regardless of success or failure, there is a need to reflect on the circumstances that led there. In failure, taking ownership of shortcomings; and in success, examining the ways in which the team worked together to kick ass.

This sort of postmortem is necessary to stay grounded and raise self-awareness. In the absence of this, it’s going to be hard to replicate success or avoid failures, especially if you’re looking to find success with another team or organisation.

Your Team Wants to Help You

Do you remember your first job, working on a team where everyone was likely more experienced than you? After a few years of experience, do you remember the last time you started on a new team at a new organisation?

I bet there were plenty of times you thought – “I can’t ask for too much help, it’ll annoy my teammates”. Even if it meant spinning your wheels on a task you had no idea how to move forward with?

✋ I’ve definitely been guilty of this.

For anyone else who raised their hand or nodded their head while reading this, here’s some food for thought:

When people assume that others aren’t givers, they act and speak in ways that discourage others from giving, creating a self fulfilling prophecy.

Research shows that at work, the vast majority of giving that occurs between people is in response to direct requests for help. In one study, managers described times when they gave and received help. Of all the giving exchanges that occurred, roughly 90 percent were initiated by the recipient asking for help. Yet when we have a need, we’re often reluctant to ask for help.

Much of the time, we’re embarrassed: we don’t want to look incompetent or needy, and we don’t want to burden others.

As one Wharton dean explains, “The students call it Game Face: they feel pressured to look successful all the time. There can’t be any chinks in their armour, and opening up would make them vulnerable.”

Psychologically safe working environments make it easier to be vulnerable, eliminating the barriers and friction that prevent people from asking for or giving help. In a new team or new workplace, hold on to your giver mindset, and start by assuming that everyone else feels the same way.

Help Yourself With Grit

As I look back on my career so far, and think about all the teams I have been a part of, the successful ones were the ones with grit. These were teams where grit was weaved into the culture, and was often catalysed into new members joining the team.

Team members enjoyed working with each other, and weren’t afraid to challenge each other while setting a high bar.

In Give and Take, Adam Grant mentions:

Research shows that above and beyond intelligence and aptitude, gritty people — by virtue of their interest, focus, and drive — achieve higher performance. This is why givers focus on gritty people: it’s where givers have the greatest return on their investment, the most meaningful and lasting impact. And along with investing their time in motivating gritty people, cultivating Grit is about setting high expectations, getting people to stretch, and getting them to do more than they thought they were capable of.

It struck me that these teams with “high grit” were also teams where there was a culture of generously sharing time and resources, to help each other succeed. Because of this, these teams tended to foster a culture of mentoring and giving, while also attracting mentors and givers from outside the team.

I can confidently say that this book has raised my self-awareness and given me another lens with which to examine the dynamics of the teams I work with. It’s an engrossing and well written book — I would highly recommend it.

Footnotes

[1] This link is to betterworldbooks.com — they “have raised millions of dollars for literacy, saved millions of books from landfills, created jobs for hundreds of people, and provided wonderful books to millions of readers worldwide” — I’m a huge fan of their mission, please consider buying your next book from them

When I was 6 years old, I remember asking my father what he did when he routinely vanished every day, for a good part of the day, to this mysterious place called “the office”. I remember him telling me that he worked with “software”. That word seemed so funny at the time. The 6-year-old me heard it as “soft wear” and immediately thought: “Hmm… my dad makes clothes for a living”.

Odd and obscure anecdotes aside, when I first started building software as a hobby, and then professionally, I had no idea where the journey would take me. I just assumed that all software engineers eventually became as good as Kernighan and Ritchie, able to create new programming languages at will, and that they had read every page of the “Introduction to Algorithms” book, with absolute mastery of the algorithms and data structures defined in there.

Yes, I grew up in the age of the internet, but from my experience with it in the early 2000s, I didn’t consider statically served pages, and a smattering of online shopping portals as “real software”. My ideas around how google and Amazon worked were naive, and I had given little to no thought to the complexities these services had to deal with, and how neatly it was all hidden away behind the simple pages I ultimately saw in my browser window.

I spent the first 8–10 years of my career as a software engineer building desktop-bound applications. I worked on device drivers for data acquisition and instrument control, built compiler features for model-based design tools, and developed user interfaces and workflows for software that was destined to be installed and operated on a desktop.

On this journey, I learned the tools and techniques to develop, maintain and debug software of this nature, and found ways to write code that would treat processor and memory resources on the host computer with care, like the scarce resources that they were.

In those same 10 years of my career, Software as a Service (SaaS) has exploded in terms of the number of software solutions and services deployed in that manner, as well as the complexity and sophistication of those solutions. There’s probably enough material to write a book (or a few) about that. As I see it, some of the catalysts for this are:

• Massive increases in network bandwidth, and how easy internet access has become in most parts of the world. Many of us are fortunate enough to be able to access the internet as easily as turning on a tap of water.

• The precipitous drop in the cost per unit of processing power, storage, and memory in the cloud, and the ubiquity of cloud service providers.

• An explosion of open-source software tools and frameworks that have allowed applications and services to be built rapidly, making the ability to quickly build out an idea and offering it as a service, a lot more accessible. In other words, you don’t need to be an accomplished software engineer with a four year degree to approach this work anymore. A lot of the complexity is hidden away (for better or worse), allowing high level thoughts and ideas to be easily and quickly expressed, and then made available equally quickly because of the above mentioned factors. Anyway, I digress.

After a few years of desktop application building, I had this nagging feeling that I was missing out on entire categories of software engineering challenges, by not working on large scale SaaS. Outside of work, building a few small applications for my own learning, and experimenting in my own time is one thing. However, I was convinced that immersing myself in problems like this as part of my full-time job was the way to go, if I really wanted to learn how to build and operate software that was resilient and malleable, and that played / orchestrated well with other services.

It’s been a year since I started working on software in the cloud, and I wanted to share some of the differences (and similarities) I have observed, when developing software for the desktop (I’ll refer to this as “desktop software”) vs. a service or application hosted in the cloud (I’ll refer to this as “SaaS”).

A few notes:

1. This isn’t meant to be an exhaustive list of differences between developing for desktop applications vs. engineering SaaS. These are just my personal (and subjective) experiences with them.

2. This isn’t about espousing one way of doing things, or another. It’s just a compilation of observations in the short time that I have been building things on the “other side of the fence”. :)

Debugging application logic

From a software engineering perspective, debugging the applications I was building using C++, Java, MATLAB etc. especially for applications where I either owned or had access to the source code, was as simple as:

1. Set a breakpoint in the source code

2. Attach to process (if already running) or run the application in debug mode,

3. Land at the breakpoint by executing the appropriate functionality, and start investigating.

For SaaS — The first time I had to investigate a bug in the Javascript based frontend locally, I spent hours trying to figure out (on my own, and asking colleagues) how to setup and launch all the right services locally, since the bug was in a part of the application which could only be accessed by performing a workflow that required the interaction of all those micro-services. At least in this case, the saving grace was that browsers come with developer interfaces to inspect and set breakpoints on Javascript code.

A few days later, I had to investigate a bug in Python source code in a Django based system that was containerized, and soon had the sinking realization that there was no out-of-the-box “Set a breakpoint in an IDE and hit Run” workflow, to stop at a breakpoint to inspect things. Yes, it is possible, and I figured it out, but it still takes more setup and preparation than I was used to.

The positive side of this is that I got much better at eyeballing code to find possible issues, and instrumenting code I wrote with logs and metrics to make sure that any bugs I introduced in my code could be found a lot faster by following the presence / absence of messages in our logging and metric collection services.

Determining usage and error issues via metrics and logging

Speaking of logging usage and errors, enterprise software running on a desktop needs to phone home, at least intermittently, to transmit anonymized usage statistics, crash reports or error logs. That is, if the user of that software isn’t behind a network and firewall that prevents this information from being sent back, or, even gave you the permission to phone back home in the first place.

For SaaS, my experience so far has been that at least for services and applications that aren’t in a private cloud environment, the provider of the service is free to make calls to a logging and metrics services to continually log information, as long as it pertains to the functioning of that application.

Why is the ability to log errors and usage metrics over the network so important? In desktop applications that are missing this functionality, especially in major / critical enterprise software, the only way you find out about major issues and bugs that were missed by multiple rounds of QA, is through a sudden influx of support tickets to your frontline support team. Ideally, you want to be finding out about these issues as they happen, and have a fix ready (or have a team working on it) before the first support call even comes in.

Leaving aside errors and crashes for a moment, in the absence of metrics, it’s hard to see how your user base is using new and existing features, assuming they have even discovered those features you spent months working on.

In the SaaS world, services like Sentry, Datadog, New Relic etc. make the tracking of logs and metrics a joy. Similarly, services like Optimizely integrated into your web application or service, allow you to run and track A/B experiments in real-time, enable or disable different experiments, or react to user issues in real time. The tight feedback loops of SaaS can be hard or impossible to replicate in desktop software, preventing access to quick user feedback around the usage of features.

Continuous Integration & Continuous Deployment (CI / CD)

Of course, those tight feedback “loops” I just referred to wouldn’t be possible without CI/CD. When I worked on desktop applications, producing a “release” was usually a major cross-team effort within the organization.

Planned releases often occurred months apart. There may be no process in place for “unplanned” releases, which means you’re forced to offer inconvenient workarounds for issues, or no solution if a workaround doesn’t exist. Even if there is a process for unplanned releases, it can take days, or even weeks to get the pieces in place necessary to produce a new release that fixes a critical bug, or an issue that’s causing a major inconvenience.

While some of this is a function of the organizational processes, size and culture, my experience was that for the development of desktop software, continuous integration was the best you could do. You could of course “continuously deploy” internally for QA or other internal uses, but without being able to continually deploy new bug fixes, enhancements and features to end-users, you didn’t reap the benefits of true CD.

Scalability in the face of unpredictable compute loads

I spent a great deal of time squeezing every bit of CPU and memory performance I could out of applications I worked on. Processor clock speeds have more or less plateaued, and there’s a limit to the number of cores you can squeeze onto a processor.

Besides, your software needs to be built to be able to take advantage of the parallelism that multi-core processors might offer, and that often isn’t the case. If you want performant software that doesn’t bog down a system, then you can’t play fast and loose with CPU and memory consumption. Therefore, when developing desktop applications, benchmarking for performance is particularly important.

In the SaaS world, you’re free to spin up multiple instances of your services when faced with a surge in load, and you can run select CPU or memory intensive services on compute resources with superior processor and memory capabilities.

Even so, performance benchmarking shouldn’t be losing its importance for SaaS. Once these services are in production, the automatic scaling (up or down) of these compute resources often masks runtime speed and memory consumption issues. I have seen cases of memory leaks going undetected for a lot longer than they would have, had those same services been running on a desktop. All because killing and spinning up new instances happened so automatically and easily.

It does take more discipline to design and implement for low resource utilization, especially for non-critical applications with no *hard* latency requirements, where it may not feel necessary.

Data Considerations

The storage and security of data had never been a concern for me, until now. Of course, this was unique to the application I was building. If I were working on, say, the desktop version of a software like TurboTax, that works with sensitive personal and financial information, having solid access controls in place would be necessary. In that case, protecting data access from malicious actors (both human, and other programs) would be the primary challenge.

In the cloud, many other degrees of freedom (to borrow a term from mathematics) open up when it comes to Data. Take for example data residency — the requirement for data to be localized to a specific geographical region. Systems and infrastructure need to be setup and configured to ensure these residency requirements are met. Failing to meet these requirements can result in serious compliance violations.

Similarly, for software solutions of a certain type, or in certain industries, clients may insist on physical separation or isolation of their data. There may be concerns around data leakage, or a desire to protect themselves from malicious tenants sharing the same physical infrastructure. This needs to be accounted for when designing the system.

Managing data access feels exponentially harder. At least when your software resided completely on the end user’s machine, apart from the due diligence access controls your application needed, the rest was up to the end user. On the other hand, for your software solution hosted in the cloud, all it takes is the production database or application credentials falling into the wrong hands. A rogue (ex?) employee, maybe a careless one, or the misfortune of being targeted by a sophisticated criminal could all lead to serious problems. In addition to all the technical steps you take to secure your data, there is a need for strong processes and a system of audits, checks and balances to ensure the security and integrity of data.

Wrapping up

There’s been a ton of learning over the past year. To be clear, I’m not “picking sides” or preaching one way of building software over the other. I chose to move over to building software in the cloud because I wanted to experience the engineering challenges that came with building resilient and scalable applications that were served this way. As an engineer who loves building user-centered software products, I’ve been enjoying the quick iteration cycles and tight feedback loops that seem to come with the territory on this side of the fence. There’s SO much more to learn, and I’m excited to see where that takes me.