7 ms·

Pioneers: people who leave behind a clusterfuck for the other engineers to build upon.

pif 7y ago
I agree with you. In my opinion, shipping for the sake of shipping and moving to other pastures is as moral as a hit and run on the road.
- satyrnein 7y ago
  Interesting analogy, and I would agree if the developer is intentionally concealing their actions to escape consequences. However, the situation is more often someone inexperienced doing a bad job, or someone experienced doing a bad job because they're crushed by unrealistic deadlines, or someone cutting corners intentionally because the company is in a do-or-die situation. None of these are immoral, but result in the same outcome.
- scarface74 7y ago
  If they shipped, gained customers and allowed the company to make money, they did their job.
  - fogetti 7y ago
    I have to ask. Does this mean that maintenance is always someone else's responsibility and never someone's responsibility directly?
    - scarface74 7y ago
      Maintenance is not a “problem” even if I am the maintainer or in my case, the “rearchiterer”. It’s what they are paying me to do. What a company needs at one phase of its existence is different than at another phase. It would be just as wrong for me to come into a company at the beginning of its existence when they are just trying to go from 0 to MVP and worry about unit tests, branching strategy, and “process” as it would be to promote the pioneer to a team lead.
drunkpotato 7y ago
That’s true! But the clusterfuck is a necessary part of the product birthing process, not something to be scorned. The baby product now needs to be nurtured and educated into a functioning adult. There are plenty of opportunities here. And this is where branding yourself comes in, to get the political power you need to do something right and fun with the product. Instead of a maintenance programmer, call yourself a “scalability engineer.” If you’re in a regulatory heavy business, read the regulatory manuals and become a “compliance engineer.” It will be super helpful for your career and give you the clout you need to make the necessary product improvements as the business matures. Just my two cents. I think you’re being downvoted because your tone comes across as scornful, but it’s really a fantastic opportunity for back end devs to make a difference.
- cjfd 7y ago
  I don't think the clusterf*ck is necessary for anything. It is an indication of immature people working on something when a product goes through a phase like that. Of course, at the stage where the project is 100 lines large one does not need much structure but it can be added gradually without a noticable disruption in the flow of features supported. The whole 'scalability engineer' and 'compliance engineer' title mumbo jumbo sounds very phoney to me. As far as the compliance part is concerned I feel inclined to make up some fake dictionary definition for it in the style of the devils dictionary for maximum cynicism. Compliance: a lot of paperwork that asserts that a set of desirable attributes apply to the mirage that management has dreamt up about a project. The mirage may or may not be in any way related to the actual state of said project.
  - drunkpotato 7y ago
    That’s a fair and reasonable perspective. I’m curious if you’ve worked on such a product that had a baked-in level of maturity from the start? I never have. I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck! Scalability engineer and compliance engineer very much are phony mumbo jumbo from the perspective of a software engineer. However from the business perspective they are very real and I think they are helpful to communicate one’s own level of maturity and ability for the business owners to trust you to get things done for them. It’s about communication and signaling more than the reality of what you do.
dnautics 7y ago
Don't bemoan pioneers. If they didn't build fast you could spend a ton of effort on a system without knowing that customers want it (I'm a planner)
- PaulStatezny 7y ago
  What about in the case where it's already known that there is a product-market fit? When Pioneers leave an absolute mess in their wake, changes to the project take more and more time. There is a trade-off, and the "immature pioneer" mindset (working with no thought for the future maintenance of the code) can make the scaling / maturing process of a product needlessly painful and slow.
czbond 7y ago
I like to think of it as - pioneers build the base enough to prove some part of product, market, or technology so there is later revenue for the engineers to have a job. I've heard tons of engineers teams whine about technical debt - without realizing that there would be no company to employ them. Pioneers tend to be good at many domains; engineers tend to be great at one or a subset of domains. Specialists refine the toolsets and methodologies, while pioneers main goal is to just help prove business value.
deanCommie 7y ago
But they left something to build upon. This is key, regardless of whether you think that "doing it right the first time" would have not taken meaningfully longer, and paid off in the long run over and over. For any meaningful product, you want to get customer feedback early and often, and you want to do it before your competitors get a chance to. I say this as a more stereotypically "Process" person/developer than a "Pioneer". I know too many failure scenarios. I overthink. I get into analysis paralysis when there is an open page. I need that Pioneer to help my company and my team get started. But give me an existing system, and I'll mold it and expand it as quickly as that 10x Pioneer. I love taking shipped hacked together code, and gradually refactoring it and improving it for 10x, 100x scalability of both system throughput and development team growth. The important factor here is shipped. In production, with customers. Customers who already see the value and benefit, and don't mind the occasional blips and glitches that will take much longer to fix (and probably require massive rewrites) to fix behind the scenes. Beautiful code without users is worse than nothing at all.
scarface74 7y ago
At least you have something. I had to come to respect this. The code may have been bad, thrown together, and not architected correctly, but, if the company was able to get customers and become profitable enough or get funding to hire people to clean it up, they were a success. The Twitter codebase was a well known clusterfuck, but they got product market fit and were able to survive long enough and become capitalized well enough to rearchitect their system.

pif 7y ago

I agree with you. In my opinion, shipping for the sake of shipping and moving to other pastures is as moral as a hit and run on the road.

satyrnein 7y ago
Interesting analogy, and I would agree if the developer is intentionally concealing their actions to escape consequences. However, the situation is more often someone inexperienced doing a bad job, or someone experienced doing a bad job because they're crushed by unrealistic deadlines, or someone cutting corners intentionally because the company is in a do-or-die situation. None of these are immoral, but result in the same outcome.
scarface74 7y ago
If they shipped, gained customers and allowed the company to make money, they did their job.
- fogetti 7y ago
  I have to ask. Does this mean that maintenance is always someone else's responsibility and never someone's responsibility directly?
  - scarface74 7y ago
    Maintenance is not a “problem” even if I am the maintainer or in my case, the “rearchiterer”. It’s what they are paying me to do. What a company needs at one phase of its existence is different than at another phase. It would be just as wrong for me to come into a company at the beginning of its existence when they are just trying to go from 0 to MVP and worry about unit tests, branching strategy, and “process” as it would be to promote the pioneer to a team lead.

drunkpotato 7y ago

That’s true! But the clusterfuck is a necessary part of the product birthing process, not something to be scorned. The baby product now needs to be nurtured and educated into a functioning adult. There are plenty of opportunities here. And this is where branding yourself comes in, to get the political power you need to do something right and fun with the product. Instead of a maintenance programmer, call yourself a “scalability engineer.” If you’re in a regulatory heavy business, read the regulatory manuals and become a “compliance engineer.” It will be super helpful for your career and give you the clout you need to make the necessary product improvements as the business matures. Just my two cents. I think you’re being downvoted because your tone comes across as scornful, but it’s really a fantastic opportunity for back end devs to make a difference.

cjfd 7y ago
I don't think the clusterf*ck is necessary for anything. It is an indication of immature people working on something when a product goes through a phase like that. Of course, at the stage where the project is 100 lines large one does not need much structure but it can be added gradually without a noticable disruption in the flow of features supported. The whole 'scalability engineer' and 'compliance engineer' title mumbo jumbo sounds very phoney to me. As far as the compliance part is concerned I feel inclined to make up some fake dictionary definition for it in the style of the devils dictionary for maximum cynicism. Compliance: a lot of paperwork that asserts that a set of desirable attributes apply to the mirage that management has dreamt up about a project. The mirage may or may not be in any way related to the actual state of said project.
- drunkpotato 7y ago
  That’s a fair and reasonable perspective. I’m curious if you’ve worked on such a product that had a baked-in level of maturity from the start? I never have. I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck! Scalability engineer and compliance engineer very much are phony mumbo jumbo from the perspective of a software engineer. However from the business perspective they are very real and I think they are helpful to communicate one’s own level of maturity and ability for the business owners to trust you to get things done for them. It’s about communication and signaling more than the reality of what you do.

dnautics 7y ago

Don't bemoan pioneers. If they didn't build fast you could spend a ton of effort on a system without knowing that customers want it (I'm a planner)

PaulStatezny 7y ago
What about in the case where it's already known that there is a product-market fit? When Pioneers leave an absolute mess in their wake, changes to the project take more and more time. There is a trade-off, and the "immature pioneer" mindset (working with no thought for the future maintenance of the code) can make the scaling / maturing process of a product needlessly painful and slow.

czbond 7y ago

I like to think of it as - pioneers build the base enough to prove some part of product, market, or technology so there is later revenue for the engineers to have a job. I've heard tons of engineers teams whine about technical debt - without realizing that there would be no company to employ them. Pioneers tend to be good at many domains; engineers tend to be great at one or a subset of domains. Specialists refine the toolsets and methodologies, while pioneers main goal is to just help prove business value.

deanCommie 7y ago

But they left something to build upon. This is key, regardless of whether you think that "doing it right the first time" would have not taken meaningfully longer, and paid off in the long run over and over. For any meaningful product, you want to get customer feedback early and often, and you want to do it before your competitors get a chance to. I say this as a more stereotypically "Process" person/developer than a "Pioneer". I know too many failure scenarios. I overthink. I get into analysis paralysis when there is an open page. I need that Pioneer to help my company and my team get started. But give me an existing system, and I'll mold it and expand it as quickly as that 10x Pioneer. I love taking shipped hacked together code, and gradually refactoring it and improving it for 10x, 100x scalability of both system throughput and development team growth. The important factor here is shipped. In production, with customers. Customers who already see the value and benefit, and don't mind the occasional blips and glitches that will take much longer to fix (and probably require massive rewrites) to fix behind the scenes. Beautiful code without users is worse than nothing at all.

scarface74 7y ago

At least you have something. I had to come to respect this. The code may have been bad, thrown together, and not architected correctly, but, if the company was able to get customers and become profitable enough or get funding to hire people to clean it up, they were a success. The Twitter codebase was a well known clusterfuck, but they got product market fit and were able to survive long enough and become capitalized well enough to rearchitect their system.