The Stages of Being an Engineer


created: Mon 28 December 2015; status: published;

Part of the `Notes to a New Engineer <https://carlkibler.com/notes-to-a-new-engineer/>`__series

On a recent project I was reminded of the different stages of problem solving an engineer goes through during a career or project. Capability grows over one's career, but it varies a lot per project. A relatively new engineer can be the domain  expert on a project but inexperienced as an engineer compared to other team members. Let's talk through a concrete example of the stages of being an engineer and how to grow your awareness of them.

The project team was discussing how to add a new feature to a UI that already held a lot of complex workflows. We were all scared of touching the code which, though well designed and tested, was difficult to understand. The team was a mix of fairly new engineer, experienced engineer, very experienced engineer/architect, and the architect with domain knowledge.

What did everyone contribute for implementing the feature?

Relative beginner: We can add a link to a separate page and put the new code there.

Mid-experience: We can enhance this UI component to handle different inputs, with auto-suggestion.

Very experienced [me, in fact]: We can use progressive enhancement to add workflow steps based on previous choice, to lead the user step by step rather than all-at-once; Fixing the caching problem will make it fast enough to be smooth.

Domain expert: Throw that page away. The workflow is just 3 discrete steps and jamming them onto 1 page is the problem. Isolate each step in the flow.

The expert's suggestion was a revelation. He was advocating an entire rethink1, based on experience and knowledge of that feature. His suggestion showed how stuck in the status quo we all were. We were thinking inside the box of this existing page and workflow. The better thing than incremental improvements to that page was to take our learning from years of tangled growth and search out the desired workflow outcomes. Suddenly, we had a new world of possibilities!

A complex presentation can mask a simple workflow

In short order we designed 4 focused pages. We broke 500 lines of complex code into pages of 30 lines each. Each step in this progressive workflow could now be enhanced and made smarter. Each step could evolve to a better experience. We had a green field ready for real innovation instead of a tangled thorny mess!

Look at the contribution of each experience level above:

Beginner - bypass the problem

Intermediate - tweak it a bit

Advanced - hide the complexity as long as possible

Expert - free the workflow from the presentation

The revelation was that a complex presentation was hiding a simple workflow. And also that each engineer contributed a very analysis based on experienced.

How do you move through the stages?

First, you observe this sort of situation. Pay attention when your team is discussing changes. You should already have identified the experienced people you should learn from. Watch how they approach the problem and try to see how they skipped steps 1, 2, or 3 to arrive at a better solution.

After identifying the better solutions proposed, take it further. Can you further simplify things? Can you drive the team deeper, down to core workflow goals? To find the "workflow bedrock" down at the bottom, you need to first see how the team is talking and try to push it further. This will move the team's thinking from evolutionary changes to revolutionary changes.

With practice and experience you will move through these steps quickly, fluidly and repeatedly on every project. That's how one progresses through the stages of being an engineer.

Find the workflow bedrock

Write down the workflow goal. Seriously, go back to basics, and write it down on a white board. Then list the outcomes the user or system needs. Work backwards from final results so you can propose wild intermediate steps and let them drive discussions.

  1. Write down the workflow outcomes (user goals)
  2. Create ideas for reaching individual pieces of those goals.
    1. What can you do automatically?
    2. What choices does the user really have to make? Decisions cost users time and energy. Minimize decisions where possible.
  3. If need be, take individual pieces of the workflow and re-examine each from #1.

[1] Often a rewrite and reinvention is a waste of time. I don't have a ready framework for choosing reinvention over improving. Maybe some day.