I would characterize myself as more of a "Martial Artist" at heart. I find creating quality code gratifying for its own sake. I have an academic CS education. The majority of my early career was spent at a mature organization with lots of process in place and a reputation for engineering excellence. I love tools engineering and other internal work that makes others more productive, rather than the trench warfare of supporting consumer apps with thousands and thousands of users.
Yet, over the past two years at startups I feel I have taken on a lot more "Street Fighter" characteristics in order to cope. I let objectively bad code slide in reviews if it puts out a fire or we won't scale to meet its limitations soon. I fix serious issues and operational headaches under the table, because they would fester for months unprioritized otherwise. I start talking directly to management at the year mark instead of waiting for raises, because most startups just don't bother setting any expectations at all on that front.
It's important to realize that not all Martial Artists will be that way forever. And your organization might be what makes them hang up their black belt and pick up some brass knuckles. Or vice versa - a Street Fighter might tire of building and rebuilding half-baked spaghetti wire solutions and decide to go somewhere they can just focus on one thing and collect a paycheck.
There are actually more pitfalls than just the nature vs. nurture argument (for example, combat based metaphors in cultures where women do not typically serve in the military are likely to affect the perception of who measures up...).
In that vein, I am more jazz guitarist than classical pianist.
"For any software project to succeed, you need three types of developers:
The kamikaze. They kick off the project, they don't care about the mountain on the horizon or the abyss less than ten clicks ahead. They get everyone on board and they will also give the column directions and keep them on track.
The soldier. They just march on and on. They may take longer to solve a problem, but they don't tire. They keep at it.
The sniper. Any really difficult issue they will just take out. But they need calm and solitude to do their deed."
Wow right out the gate I have absolutely no clue what it is going in this article.
Even though it's unsavory, I did use a "scrappy street kid fighter" analogy on HN a couple months ago, criticizing some academic attempt to make declarations about software engineering. Then spun that into one of my favorite topics, which is startups and other smaller companies playing house self-destructively, by cargo-culting behaviors of insulated massive megacorps. https://news.ycombinator.com/item?id=34753570
Instead, we need to lean more towards scrappy street-smarts than we have been during much of "tech". (We also need to always learn from our predecessors and conteporaries, but to be smart about it, not cargo-cult, so I'm focusing on the smart part first.)
If a wall did accidentally appear in a scrappy org, maybe the wall gets knocked over, and the trash collegially tossed back, with an offer to work together on something that will work?
Stereotypical lumbering bureaucracies can appropriate terms all day, and people mimicking them can also mimic their appropriations, and management books can be marketed, all while ignoring the actual useful meaning of the terms.
When you’re in the ring, forget the theory, do what works (within the rules). If your instinct says to throw a weird punch at a weird time, do it. You probably saw an opening.
I also like that boxing is full contact. No amount of katas or whatever will teach you as much about yourself as getting actually punched in the face will.
Similar to how no amount of analysis can beat actually shipping software and seeing what customers say.
I suppose we have to be careful not to rationalize mindless flailing, when we should be keeping our heads and mixing levels of intuition and thinking appropriate to the occasion. (Rather than throw random things at a customer each sprint, and purely react, we can be smarter about what we throw. Also, a one-week sprint isn't about acting in the moment of a hundredth of a second.)
Excellent point!
Competitive TKD practitioner: "Approaching this match, aware my opponent was a highly-ranked veteran competitor, I asked myself: what would a techbro do?"
Human cross-domain capabilities are amazing.
Meyer would evaluate a series of varying weights of golden hammers. Try to defensive code all possible cases. Find a decisive insight into a problem.
And Polish sabre school would cut off the angles until the solution is all that remains possible. Feint all sorts of evil cases for testing.
Now the fun part is that basic principles are the same.
You write code that works and does what is required or you are not a programmer.
You win swordfights or you're dead.
Both of the swordmasters worked from first principles...
Another analogy would be someone talking about their music like (a) code.
Which is good and bad, in a society in which he can do almost anything he wants, and almost no one will tell him no.
> There are basic ground rules (clear requirements) which the opponents (problems) are NOT allowed to break. eg: below the belt punches, (changing priorities every week) etc.
Who does get to work in such an environment? I can only think of:
* Academia
* Artificial environments (e.g. leetcode, coding competitions)
* MAYBE very mature products in established companies
For the vast majority of us changing requirements, unknown unknowns and technology shifts are our daily bread. Big, unchanging upfront design doesn't work, and we've known this for several decades now.
If you're working on an existing service and not building new features/functionality (E.g. you're improving scaling or optimizing performance like he mentions) the problem space is usually pretty well defined and you can mostly just put your head down and work.
What I like with this article is the difference in how you approach a problem depending on how you are functioning as a human being. Of course it is nowhere near of the real world, but I think all of us can identify people we worked with who are really efficient on both of these "sides".
Over time I'm becoming more and more aware of non-skill factors that affect my impact.
I'm definitely more a street fighter, and I feel limited when I'm given martial artist work and there is very little opportunity for street fighter work.
I think it can be very difficult to be a 10x engineer because you have to be in an org that has the right type of work, be on a team that's involved in that work, and be in a role in which you're given that work.
Working at a big company as a SWE (As opposed to e.g. SRE) I've found that the street fighter work is very limited and generally only specific teams and people get to work on it.
Agreed. I noticed that 10x engineers are a product of 10x workplaces. Orgs have insane ability to take the most skilled engineers and make them unproductive.
- https://erikbern.com/2016/01/08/i-believe-in-the-10x-enginee...
- https://erikbern.com/2019/02/21/headcount-targets-feature-fa...
What closed group would that be, since by definition they are not part of a particular group? A martial artist sounds like the guy that got a product of the ground and would likely be part of the founder group; not likely looking to do it again.
> I have worked with 2 types of 10x engineers so far: Martial Artists, Street fighters
It then goes on to say which you should have. Duh if they're each 10x, both.
The article set up a false dichotomy in its premise.
"The Gamesman" (Maccoby, 1978) divided workers into "craftsmen", "organization men", "jungle fighters", and "gamesmen". Same concept, earlier decade.
Freudian slip? :D
They have no use in a real fight, but companies are full of them.
IMO, the street fighting skill is a bit less known. I worked for a unicorn which had ZERO managers and ZERO Product managers. The engineers had to speak to the users, write the roadmaps, build stuff and report to the founder. I realised this skill was rare among engineers and less talked about. Initially, I titled this "Street fighting engineers", it eventually evolved into this.
Unless these people make their role known, most other people don't see all the firefighting that they do.
Being able to craft quick and dirty solutions which are diluted versions of my normal code solved tons of problems. Since I see programming as a craft, I had an intuition about where I can cut corners without affecting the quality most of the time, and I can add the corner back if the opportunity arises.
A martial arts practitioner with a flexible mind is a formidable force.
These are techniques martial arts teach. A "street fighter" might have some tricks up their sleeve, but a martial artist is better equipped to handle arbitrary conflicts they may find themselves in.
Neither guarantees success in a fight.
