Implementers, Solvers, and Finders | Hacker News Reader

Implementers, Solvers, and Finders

rkoutnik.com

164 pointskiyanwang15 comments

A lot of start-ups in my experience see all their engineers as “high-autonomy feature implementors.” It’s not really autonomy in the sense of power or choice, though, just being left alone to implement features. The thing is, “features” are product-level things that require technical design as well as implementation. Product design and implementation and technical design and implementation are all different things. Even within programming, implementation has sub-problems that require creativity. I implemented a Java VM, once, for example, and it was really fun. So it’s not necessarily the case that once something is a matter of “implementation” it is just straightforward work to give to a junior programmer, or that implementing things is boring.

What sucks is, for example, being good at technical design but that not being valued. And management being disconnected from employees, which is not unique to software companies.

This post made me realize why I am hesitant to leave my role in a struggling start up. I get paid to discover what our problems are and solve them as fast as possible which leads me to constantly learning new skills and fully owning our product and R&D output. I like that more than the lack of job security and must be why I've been so resistant to searching for a new more secure position.

I was once like you. And I'm here (~50 yrs old) to tell you the experience you are gaining right now is setting you up for great success in the future, should you choose to stay in the field of software. I mostly worked at small companies for the first 80% of my career where I wore many hats. Then I moved to a larger, more corporate employer and was astounded and how little experience my colleagues had with databases / message queues / mail systems / ad servers / analytics / monitoring / alerting / etc.

All that to say it sounds like what you are learning in your current role is extremely valuable; worth so much more than your paycheck[1].

1. offer only applies if you are young-ish and planning to stay in this industry. good luck!

I'll also say that this experience sets you up nicely to work in a position adjacent to programming, should you desire that. I'm talking about:

* product management

* technical training

* developer relations

* technology consultant

Being able to move between the clouds and the dirt as well as solving problems (or marshalling others to help you solve them); these are skills that are golden.

Hard to convince when on a resume, ime, so make sure you keep your network up to date and/or learn in public.

This is not to invalidate the point made by sibling comments, just that I'd like to offer a different perspective borne of a different experience. Should you ever decide to move into a Big Co, you may find that they don't value your startup experience to the extent you think they should. Most Big Co's take a pretty linear approach to hiring. Jump through leetcode hoops and a "system design" module. Sadly the fact that you ran tech base of an entire company by yourself does not matter to them. Now, of course, not all Big Co's hire like that and you may not even want to go to Big Cos. But life situations change (marriage, kids, emergency expenses...) and you never know how long things will last. At least for me, it was a rude awakening how little value companies actually put on startup experiece.

Same here. The reason I'm not taking another job/position is exactly that my current one offers me free hands to work on R&D stuff on a scale where with some help I get to implement stuff myself. Next obvious step would be a technical manager in the same organization, but I can't seem to be able to push myself knowing other things that would be required of me (non-technical).

This reminds me of another framework for thinking about roles that I've found useful: "Planners, Settlers, and Town Planners"

https://blog.gardeviance.org/2012/06/pioneers-settlers-and-t...

https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...

Pioneers*, Settlers, and Town Planners.

It reminds me of the distinction someone made between marines, soldiers, and police, or something like that

Wardley says: “The concept of Pioneers, Settlers and Town Planners is a derivative of Robert X. Cringely’s description of companies as Commandos, Infantry and Police as expressed in the delightful 1993 book – Accidental Empires.”

I imagine that this show go without saying, but as it wasn't explicit in TFA, I'll throw it in here.

These distinctions represent points on a continuum, they aren't (except perhaps at the limits) exclusive.

But the mix is also part of the choice that you make, or that is thrust upon you, as a finder, how much solving and/or implementing should I still do? Too much and you don't get any finding done, too little and you can become out of touch.

I've encountered people who have gotten this wrong, and I have definitely gotten it wrong myself too

I love how well this framework maps to academia — PhDs are implementors, Post-docs are Problem-solvers, and Professors are Problem-finders.

There's also two dimensions.

You might be an implementor from a product management perspective, but a solver from a technical perspective. Here's a desired feature, figure out how to make it work.

Or you might be a finder from a product management perspective, and a finder from a technical perspective. Here's the vision, figure out what feature should be added and figure out how to make it work.

You've left the door open for a product management finder solution implementer. You figure out what problem to solve but you must use AI/Blockchain/Kubernetes to solve it.

While this article contributes a valuable analysis, what I have been looking for in my own teams is that devs get out of their selfish space and start to see what their fellow dev needs, what the team leader needs, what the project needs. Many devs get caught in the thick of coding and miss the forest for the tree. And I get that, but software engineering is a group effort that faces challenges not restricted to code only.

This is really relevant to what I've been struggling with for over a decade but am currently in a position to define a structure from the ground up. Thanks OP for your timely submission. It's nice to have someone outside the ride stand up some ideas I can argue with.

Reply on news.ycombinator.com