When you’re creating brand new software, life is simple. Your focus is exclusively on the functionality of the software. It’s a care-free, liberating world. Coding is an act of pure creation. If you can think it, you can build it, and typically very quickly. You could see a change in production just a minute or two.
There’s so much you don’t have to think about or acknowledge, at all.
Your focus is exclusively on the behavior of the thing you are trying to build. It’s like running through a green field with your eyes closed. You can run full sprint ahead and absolutely fly without worrying about hitting anything.
If you want to add a new page, go ahead! If you want to add a textbox somewhere, you can! Just do it.
In this green field, a textbox is just a textbox. It only takes a minute to add it.
Then, you start seeing success.
People start using your software. People start charging money for your software. Your software starts to become a product. A business forms around it. Customers start requesting things, and more importantly: they start depending on its continued functioning and existence.
People start asking for more. More capabilities. More features. More connections with other things - things that were never meant to be connected to. Other people start making decisions for thing you’re building. You can’t even call them people anymore, now they’re called stakeholders. The green field becomes a tangled bramble of needs and requests. It becomes muddy.
The brown field
In this brown field, the textbox is no longer “just a textbox”. There’s so much more to it. There’s business rules, often lost in nuance.
Rules around:
How it’s displayed - masking, borders, colors, shapes, sizes, positions, margins
How it’s tracked - analytics, auditing, tracking who, when, and where
How it’s accessible - screenreaders, mobile, translations, color-blind support
How it’s secured - character limits, XSS prevention, rate limiting, authorization
How it’s validated - input rules, how errors display,
How it’s expected - stakeholder training, user habits, data migrations
How it’s operated - cost control for usage-based vendors, feature flags for visbility
How it’s maintained - rules in one usage vs. another, reusability of its functionality
How it’s observed - error handling and reporting, notifications if it breaks
How it’s communicated - loading indicators, animations, user delight, labeling
How it’s scaled - paint and render performance, server optimizations
How it’s effective - A/B testing of impact, pre-filling of data, ease of completion
How it’s used - if users understand it, if they make mistakes, if they’re faster
How it’s valued - why customers want it, why the business needs it, if it matters
…and so much more.
The textbox isn’t just a textbox anymore. It’s an entire ecosystem with a long history of past decisions, some forced by the context, and others made by dozens of people all without awareness of the other decisions. It’s connected to other elements with just as much complexity, all likewise interconnected in mysterious, likely undocumented ways. Some of those decisions may be written down or remembered, others not.
Hidden complexity
All of that complexity isn’t visible to any single person.
If you aren’t a marketer, you won’t notice that it can be targeted by the tag manager. If you aren’t visually impaired, you won’t notice it has screen reader support. If you aren’t using an lower-end machine you won’t notice it’s been made faster. If you don’t speak another language, you won’t notice it has translation. If you aren’t coming from another site, you won’t notice it pre-populates. If you aren’t the finance leader, you won’t notice the revenue impact. If you aren’t the auditor, you won’t notice the DOM has a label that’s technically a violation of a long forgotten rule.
Yet, you as the engineer still have to consider it all. You have to reckon with and factor in these decisions as you define and implement change after change after change - all under what always seems to be a tighter and tighter deadline.
In the green field, hours was enough to build an entire product. In the brown field, it’s sometimes barely enough to understand what a request is even asking for.
You have to make changes within the constraints of the past and future, known and unknown. Changes will eventually break something, and the affected party will fill a bug report which you have to then complete and fix.
That’s the price of success - people use the software and notice when it doesn’t behave according to how they think it should.
How should it behave?
It’s the hardest question you might be able to ask someone at a company that’s been around for a while.
The stakeholders in the company won’t be able to define it for you. Nobody actually knows the intricacies - not in full. You have to discover it.
So, you talk to users to find our their needs. You analyze how people are using the product. Where they get stuck. Where they click and don’t click. Where they enter. Where they leave. How all that translates into the how the user gets their job done and the company accomplishing their goals.
But, that’s still not enough.
Knowing what you intend the software to do is just part of the problem. You also have to know what it was intended to do and how it works today.
There’s no easy map - just code and history. To find it, you have to do good old fashioned archaeology. You search commit histories, Slack discussions, old documentation, random meeting notes, talk to co-workers, view logs. Bit by bit, you’re able to build context that makes your follow-on decisions implementing more accurate.
Speed vs. Accuracy
The challenge is - context building takes time. It’s time away from developing and coding. It affects the speed at which you can deliver the change. It might be too slow for the tastes of the company or your manager. You might even feel you aren’t really an engineer anymore.
When faced with the prospects of having to have “conversations about your throughput”, you might try to reverse course: moving faster, deciding faster, acting faster.
Rookie mistake - all that does is just cause you to miss some hidden interconnection nobody knew about and cause an incident. Now, you just traded the throughput conversation for one about quality.
At this point it’s easy to get frustrated. The natural tendency of an engineer is to push back. You might start to reject tickets due to “incomplete requirements”, or start approaching every change request like a contract negotiation, requiring volumes of forms to be defined and filled out.
That approach won’t work. Asking others to define it won’t help because they don’t know. They don’t have the knowledge, nor do they have the time. As the engineer, you at least have the advantage of being able to look under the hood and live in the product. For some of your co-workers, they only think about the product for 30 seconds a day - they have other day jobs they have to do.
It’s up to you to figure it out. The more you dive into it, the more you can grow and improve. Embrace the breadth. It’s not just about the technology.
Becoming a product engineer
When you’re a product engineer, you have to “wear a lot of hats”. The product hat. The finance hat. The user hat. The engineering hat. The investor hat. The customer hat.
None of them will seem like they fit.
You might find it hard to think about things from each of the perspectives. To wear each hat and truly adopt that persona as your own, even just for a minute. To think through a problem as if you were the person the hat was made for.
Well, nobody said Product Engineering was easy.
It’s difficult. It’s high pressure. You’ll constantly hear questions from stakeholders asking “Why can’t we go faster?” and “Why can’t we stop breaking things?” They might even start comparing you to other teams and other companies, not realizing those teams are on newer products and in greener fields.
It’s easy to feel stuck - to feel that any move you make is going to be wrong.
Grind away at it anyways. In situations like this, the only winning move is to lose and learn.
The mistakes will happen. Focus on improving, learning, and sharing knowledge. Focus on getting the job done.
Little by little, it’ll get easier. The patterns will get clearer. The cause and effect will start becoming automatic. The chaos will turn into complexity which will turn into simplicity.
You’ll start thinking deeply. Thinking about how the users will interact with the change. How it’ll impact the business. What they’ll expect. What they’ll want. What they’ll need. It’ll just become automatic.
You start being able to avoid problems entirely, and to find insights that have a huge impact. It’ll become second nature to think about things like accessibility and scalability while thinking about revenue and compliance and usability. You’ll be able to see the thread of how the click will translate across 20 hops to impact the bottom line.
It’ll all makes sense. It’ll all connect. You see it in your head, with every decision you make.
Being an expert
The next time you need to add a textbox, you’ll be more confident. You’ll consider the impact - to everyone: users, customers, the business, your peers, your system, your product, yourself. The non-functional requirements that many don’t even know exist, you’ll just consider through your minute-by-minute actions. You feel like you’ve got this. You’ll know you’ve got this. You’ll be wiser, faster, better.
It’ll take just a minute to add the textbox: a long journey to arrive at the same destination.
But not quite. This time, you’ll have considered the “-ilities”. You’ll have considered the things not mentioned. You’ll have done the things not thought about. You’ll have considered things that aren’t relevant now, but will be soon. You’ll have factored in the past, present, and future.
You’ll complete your ticket - not what was defined, not even what was intended, but what was needed. Whether the field is green or brown won’t matter anymore.
You’ll be happy with the result. You’ll have made it look easy. It actually will be easy.
After all, it’s just a textbox.