41 ms·

This is jaded and angry, but I think there is another archetype called "the politician." They play the game extremely well, providing poorly thought out solutio

This is jaded and angry, but I think there is another archetype called "the politician." They play the game extremely well, providing poorly thought out solutions quickly to problems they haven't dug into the complexity of. They lay operational traps everywhere in their quest to get things done fast (like directly embedding config data in code to avoid fixing the config format). Once they've picked the low hanging fruit and left too much complexity to maintain, they hop to another company where they sell themselves on all they accomplished leaving out the absolutely unmaintainable mess they left behind.

maerF0x0 4y ago
Next level politicians do a really broken implementation first cycle so they can deliver a solve next quarter for eye popping data driven results. I've personally warned people about terrible designs, saw them get implemented, they cost the company millions, but then they "improved" it next quarter to save the company "millions" ... They got promoted, I got called names like "too negative"... Great company.
- eftychis 4y ago
  I am guessing most/a lot of us have seen similar situations (unfortunately). (Sometimes, though situations like that are unavoidable -- given that demos can become product overnight or a deadline is unattainable no matter what you shave off. If I had a nickel for each time I had seen any of the above happen...)
  - maerF0x0 4y ago
    yes there are shortcuts that one takes for a demo, but these were multimonth projects extending existing systems, it's not like the optimal solution was going to take much longer (if at all), we just needed an architect that understood computer science I think my biggest failing in my career is in being able to convince people that just because they don't understand something doesn't mean it's harder to code. Many O(n^2) solutions take just as long to code as O(n), for example...
ble 4y ago
I usually think of an at-work "politician" as somehow taking advantage of relationships or social forces. What you describe sounds more to me like the ""10X engineer"" (with extra scare quotes for good measure). Many people have been skeptical of the idea of the 10X engineer. One take is that if your normal engineers are less than 1/10th as productive as another engineer and all of them are merely human beings, there might be some common organizational problems that your normal engineers are all being stymied by. Another take is that your 10X engineers can only achieve their high level of productivity through taking on more technical debt than others understand or would tolerate, leaving messes behind for the eventual maintainers to fix.
- eurasiantiger 4y ago
  Or maybe they just type faster.
- bioemerl 4y ago
  In the workforce - the real answer is that the 1x engineers really really aren't operating at full capacity. You assume all parties give it their all. They rarely do. Get through college Do what you have to in other to get the job. Do what you have to in order to keep the job. 10x people do some very basic things. They care. They read about code. They have side projects. They improve their skills because doing so is fun. In a company that hires "the best" and pays very well you shouldn't see a 1x 10x divide, assuming they hire well. In those that don't, those that only want work done and don't particularly care? That's where the dichotomy presents itself. There is nothing inherently wrong with either group. Work gets paid, you don't have to be a magical 10x engineer to be worth the salary. And there's no shame in coding as a job instead of as a hobby.
  - CobrastanJorji 4y ago
    "Hiring well" or hiring "the best" isn't a panacea. People change. Before I had kids, I was working hard, working late nights, and some of my work was all-consuming. After, I've definitely had periods where my main focus was on showing up to meetings and making sure I got at least pretty okay on my performance reviews, while actually focusing on, y'know, not work. If the company doesn't punish people for becoming half as productive, a lot of the folks are going to become half as productive, even if they were "the best" at some point. Especially true when morale at a company drops. Canceling projects, being assigned to boring projects (the next year will focus on Sarbanes Oxley compliance, guys!), having your company or work dragged through the news, it adds up, and people get detached.
menor 4y ago
I'm not sure if I'd name them "the politician", because I think they are not doing the harm consciously, but I've met several of them. Pair it with the "CV builder" ,that just throws new technologies at problems to add them to their CVs, and now your codebase is a minefield.
sbf501 4y ago
Since we're being anecdotal: I think that claim is jaded and angry, and makes me wonder what kinds of companies people have worked at. Honestly, I've only encountered this once or twice, and I've been a career engineer since 1989 at places like IBM, Intel, and Microsoft. Dozens of positions and groups, and I've never had to play politics. Maybe I've just worked at "good" companies (irony noted), but in my experience it was less about politics and more about getting shit done, and if you failed to get shit done, you were alerted to that very quickly. If you did get shit done, and got it done well, you got promoted, and were given even more shit to get done. Upper management at those big three had their game tight.
- vsareto 4y ago
  Just like there are loads of average developers, there are loads of average companies. You can get lucky and work at all great companies in your career. Most of us will not have enough jobs in our lives to get a representative sample. There is also a question of having different standards. Bad companies might just be bad for someone who has access to the top companies, but otherwise great for average workers.
  - sbf501 4y ago
    Point taken. My comment is a good example of "tech privilege".
- tayo42 4y ago
  im actually amazed you never ran into politics at work. you never needed to navigate around egos to get what you want, you do every thing purely on merit, every decision is only technical? my whole career as been filled with stuff like people forcing their pet projects on the company, people hiring their friends and dealing with their in crowd
  - sbf501 4y ago
    > you do every thing purely on merit, every decision is only technical? Yeah, honestly. The vast majority of my hard decisions I made were based on schedule and resources: having to kill things or move people around. The only "political" anomaly I witnessed was that it seemed the employees at the Israel Design Center at Intel were getting promoted to principal at a much faster rate, and with much less years and experience, for what didn't seem like actual merit. But that didn't impact me other than some jealousy, because the line for principal promotion in my division(s) were very long with really really smart people. And I've seen many principals get shown the door for poor performance. One possibility is that I never reached a level where politics mattered, or teams were small enough that it didn't have time to foment. And there certainly people who lived to become managers because they thought it was a status symbol, but I was happy for them to do the job. Another could be that I'm just... well, daft. Both are possible. :)
bgro 4y ago
This is almost exclusively what I've encountered in most of the "elite" engineers. It's frustrating because they're the ones saying coding and job hopping is easy. They're the ones in tech interviews who downplay your achievements. In my experience, rather than leaving for another company though, they're often a C-suite favorite and get to start some new project (often it's whatever they want to do as long as it's remotely justifiable). They get it up to 80% complete so they can hand it off to another team to do the last 20%. Since the project is whatever they want to do, they use very unusual languages or design choices that the new team has to pick up and fix. A lot of times it's whatever the big new thing is. (For example, expect statements like this: "Everything is obsolete legacy code now that Electron exists!" "No need to keep this standalone offline test database, setup shell scripts, or maintain the environment setup guide because Docker will automatically solve all of these cases!") They continue getting new projects because these 1 or 2 people "did the project 80% complete in 1 month, and the last 20% is taking the handoff team of five at least 3 months to do." Bonus points when it is expanded from some sort of hackathon, or some fake story about how some person completed the 80% portion over the weekend. In the former, all the connections and APIs are hard-coded and faked for their demo. In the latter, they had actually been working on this for the past couple months instead of doing their assigned work which made their official team look even less productive. I was on the teams always picking up the last 20%, but I got moved onto the 80% team once. I was amazed at how much code I could blow through with time to spare when I didn't have to worry about all the edge cases and minute details. Unfortunately, I got temporarily moved onto a company-wide prod support team which then got cut due to covid. Hooray.
- lioeters 4y ago
  The story reminds me of the so-called 80/20 rule. > Microsoft noted that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in a given system would be eliminated. Lowell Arthur expressed that "20% of the code has 80% of the errors. Find them, fix them!" More relevant part: > It was also discovered that, in general, 80% of a piece of software can be written in 20% of the total allocated time. Conversely, the hardest 20% of the code takes 80% of the time. https://en.wikipedia.org/wiki/Pareto_principle#In_computing https://en.wikipedia.org/wiki/Pareto_principle#In_computing It sounds like you were often stuck with the toughest 20% which actually took 80% of the effort. I also heard that of that 20%, there's another level of 80/20, where a further 20% takes 80% of the rest of the effort, and so on. Anyway, I hope you find a better situation!
jacobr1 4y ago
There is also the "positive" version of the politician. They have enough technical credibility, social skills, relationships with senior management, to remove organizational log-jams. Other companies might hire a consultant to come and tell them what they already know they need to do (but can't organizationally agree to do) - but with this archetype, you can call them in and they will cut out the bullshit, somehow without upsetting everyone.
- hayst4ck 4y ago
  I think that description matches the articles "architect" archetype: > The Architect is responsible for the direction, quality and approach within a critical area, both today and stretching into the multi-year future horizon. They combine a deep knowledge of technical constraints, user needs, and organization level leadership. The reason I labeled it politician is because they are primarily using their position for self-gain. A general definition for politics is any time the inequality company > team > self is violated (at least in terms of compensated work). I generally agree with that definition. That is why I used the word politician.
- davewritescode 4y ago
  I have found myself in this archetype before. Management wanted a feature, went to the architects and got some INSANE estimate that couldn’t be justified by the revenue that would be coming in. Management felt like they were being told to fuck off with crazy estimates and they weren’t completely wrong. I was asked to review the proposal by a VP, came up with some simplifications, presented it back to the same architects and we delivered it for 10% of the anticipated cost and the feature was profitable in year 1. It’s had no defects because it was a simple design. Sometimes you need people who can speak to managers and engineers with credibility to get things done.
  - qznc 4y ago
    Most people have a very cynical view of politics and I can emphasize. However, I try to stay more positive about it. Politics, for me, is about making decisions in groups too large to just talk with everyone. In such circumstances “bridge people”, like davewritescode, who can communicate with multiple factions are very valuable for progress. Sadly, especially in large “safe” enterprises people don’t want to learn this. Developers blame managers for “not understanding software” and managers blame developers for “lack of business understanding”.
jameshart 4y ago
There are people who are bad at every job. That doesn’t mean that the people who are hiring people into that role are looking to have someone do it badly. Or that anyone who wants such a role is automatically suspected of having nefarious motives. These role archetypes are descriptions of realistic, reasonable expectations for high level IC roles. It’s a useful, positive contribution that will help engineering directors and senior coders better negotiate clearly defined roles and responsibilities. It’s just not constructive to say ‘but yeah, sometimes when you employ someone at this level and you don’t clarify the role or hold them accountable, they do terrible things and it enables charlatans to prosper!’ Sure, of course it does. But this article is a useful and constructive model for helping prevent that from happening. What you frame as an addition to the article actually represents a cynical undermining of its entire value. I think that’s a sad way to engage.
woah 4y ago
Their crappy code might be generating millions of dollars in revenue while you fix it and curse their name
- hayst4ck 4y ago
  True! But it might also grind the company's ability to release features to a halt creating a stagnant stock price and an underwhelming IPO because they chose to avoid the hard work of migrating, refactoring, and simplifying, or setting a culture of maintainable code preferring more easily marketable (and probably more fun and less failure prone) feature work that also looks much better on a resume.
  - scarface74 4y ago
    Counterexample: Twitter. Every indication is that the code base was horrible. They found product market fit, got funding and went public. Amazon codebase was also famously barely held together by duct tape for the first few years
    - hayst4ck 4y ago
      I'm not trying to say that you can't incur technical debt if you pay it off. What I am trying to say is that a culture of technical debt stagnates growth. I would point to twitter as an example of the point I was trying to make, so I don't think it's a very good counter example: 11/07/2013 $44.9 117,633,000 $45.1 $50.09 $44 10/06/2022 $49.39 68,511,080 $50.98 $51.55 $49.29 Practically no sustained growth in almost a decade. Poor code and operations hampers the ability to prototype new features and destroys innovation.
      - icedchai 4y ago
        Yes, Twitter's stock has basically gone nowhere, just like its product. (I'm a TWTR bag holder. Hoping to get a pay out from Musk soon!)
      - scarface74 4y ago
Aeolun 4y ago
How does that work exactly? I can absolutely commit an unmaintainable mess directly to master, but I’d be very quickly called out by my team.
- hayst4ck 4y ago
  Very large portions of some very major companies have <4 years work experience. Couple that with incredibly large engineer to management ratios and that inexperienced devs are often placed under more experienced ones, and the ability to call out unmaintainable code starts to diminish. A lot of these prolific devs will not see the code base complexity for the "tragedy of the commons" it is, and bemoan the people and teams who start to try adding "regulations" (meetings/code review) to protect the common because it slows down their ability to meet their management given goals. There is also a magic phrase that frequently disarms attempts to prevent bad code from entering a code base "this is just temporary." It's easy to put off fixing the "temporary" code forever as other things become higher priority. Often times someone will inherit a staff engineer's code and therefore won't have been able to stop it. Sometimes staff engineers are able to create an entire service with minimal review that is then "gifted" to a team to refine and maintain. In a lot of these situations, the feedback mechanisms (yearly peer review) will limit who can give feedback about who, not to mention they are not anonymous and staff engineers are usually highly connected.
- dilyevsky 4y ago
  Easy - you rope other engineers in to work on the implementation. Then if it works out you claim the credit, if not either scrap the project due to “change of direction/reprioritization” or throw them under the bus.
- a_puppy 4y ago
  It works because management is bought into the politician's bullshit. So if another team member tries to call it out, then the manager labels the other team member as "hard to work with" (https://lethain.com/hard-to-work-with/ https://lethain.com/hard-to-work-with/) instead of holding the politician accountable.
29athrowaway 4y ago
Example: Dennis Nedry Prior experience: Solution architect at Jurassic Park. Present: Dinosaur food
didip 4y ago
The politician is totally a thing at large FAANG companies! It took a while for people to figure out their BS and when it's finally unearthed, two years has passed and they are ready to move on to another team or company and repeat the cycle. Sometimes they even get a promo before their rube goldberg machinery is finished and someone else had to take the fall.
- scarface74 4y ago
  You have to be a politician at a tech companies. Your promo docs depend on it. How can you show “scope” or “cross team impact” without some amount of politicking?
Olreich 4y ago
> They lay operational traps everywhere in their quest to get things done fast (like directly embedding config data in code to avoid fixing the config format). Specific to your example, rather than the sentiment, I think embedding config in code is highly valuable when you don't have a lengthy deployment cycle and have direct access to the source. It gives your compiler more information which can help prevent bad configurations (which are the cause of failures more often than anything else from what I've seen). Developers also have a better shot at feeling how badly configurable a particular component is when the configuration is code. It's much easier to hide the overly-configurable systems under a rug when the configuration is far away from implementation, in a DSL, in a different repository, or only visible at deployment.
- acedTrex 4y ago
  I agree, configs in code are not a bad thing necessarily if they don't change often or at all. Sprawling config files are a significantly higher challenge to get your bearing with.
  - FranGro78 4y ago
    I’ve been trying unsuccessfully to get buy in on config as code. Instead we have property / yaml files, read into anaemic “classes” which do not perform validation themselves. Validation duties are also foisted onto other parts of the system. Stacked onto that we sometimes have file name based convention for defining a hierarchy of configs, to save on repetition between environments.
    - hayst4ck 4y ago
      Config as code is fine as long as it results in a fully realized config that is then consumed by other code. All the big companies have almost certainly done it. I would make sure when implementing it you have someone who is very opinionated review all configs to ensure that the same behavior is always implemented in the same way until a linter can enforce idioms. I would avoid explicit conditionals and explicit loops, instead relying on implied conditionals and implied loops. I would absolutely not use any "live" data, meaning the code should be relatively pure without any dependencies. Pystachio is not a bad choice in python land: https://github.com/wickman/pystachio https://github.com/wickman/pystachio
spaetzleesser 4y ago
This describes the “enterprise architects” at my company. They read a few white papers, make nice PowerPoints, send the work to some offshoring company. The systems produced either don’t work or have serious problems but in the meantime they have already moved into another project and leave cleaning up the mess to other people.
dimgl 4y ago
This is 100% accurate. In fact, I think I've met a couple during my career.
TheDudeMan 4y ago
What is the difference between code and config, other than one is well-typed?
- hayst4ck 4y ago
  Config could be put into a database and queried while code doesn't have a sensical database representation. Even when config is code (which is almost guaranteed to happen as a config requiring system is developed), at some point in the process there is a representation that could be meaningfully stored in a columnar database before it's consumption. Code is generally considered stateless, asking for an input and providing an output that is determined only by the code and the input. Embedding state inside of code is generally a pretty grievous sin, although some places are vastly more sinful than others.
gorgoiler 4y ago
That’s a great technical example. How many times have you encountered an engineer who wraps up their tool’s interface and exposes its functionality through a YAML config file when really it should have just been left as a programmatic interface? The hubris of the engineer is in believing they’ve thought of everything anyone could ever want to do with their tool. Imagine if a shell only let you set your PATH via a static config file filled with strings. It’s probably fine 99% of the time but at some point someone somewhere is going to start programmatically building paths.yaml. Yuck.
michaelcampbell 4y ago
I'd wager the "product manager" equivalent of this is even more widespread. They constantly disallow tech debt sprints or work to happen, in order to get that nifty new feature out the door quickly in and will tackle the cut corners and tech debt "later, after MVP" or somesuch nonsense. Then by the time that debt must be paid, they're off to another team|org|project. I've seen it way too many times.

maerF0x0 4y ago

Next level politicians do a really broken implementation first cycle so they can deliver a solve next quarter for eye popping data driven results. I've personally warned people about terrible designs, saw them get implemented, they cost the company millions, but then they "improved" it next quarter to save the company "millions" ... They got promoted, I got called names like "too negative"... Great company.

eftychis 4y ago
I am guessing most/a lot of us have seen similar situations (unfortunately). (Sometimes, though situations like that are unavoidable -- given that demos can become product overnight or a deadline is unattainable no matter what you shave off. If I had a nickel for each time I had seen any of the above happen...)
- maerF0x0 4y ago
  yes there are shortcuts that one takes for a demo, but these were multimonth projects extending existing systems, it's not like the optimal solution was going to take much longer (if at all), we just needed an architect that understood computer science I think my biggest failing in my career is in being able to convince people that just because they don't understand something doesn't mean it's harder to code. Many O(n^2) solutions take just as long to code as O(n), for example...

ble 4y ago

I usually think of an at-work "politician" as somehow taking advantage of relationships or social forces. What you describe sounds more to me like the ""10X engineer"" (with extra scare quotes for good measure). Many people have been skeptical of the idea of the 10X engineer. One take is that if your normal engineers are less than 1/10th as productive as another engineer and all of them are merely human beings, there might be some common organizational problems that your normal engineers are all being stymied by. Another take is that your 10X engineers can only achieve their high level of productivity through taking on more technical debt than others understand or would tolerate, leaving messes behind for the eventual maintainers to fix.

eurasiantiger 4y ago
Or maybe they just type faster.
bioemerl 4y ago
In the workforce - the real answer is that the 1x engineers really really aren't operating at full capacity. You assume all parties give it their all. They rarely do. Get through college Do what you have to in other to get the job. Do what you have to in order to keep the job. 10x people do some very basic things. They care. They read about code. They have side projects. They improve their skills because doing so is fun. In a company that hires "the best" and pays very well you shouldn't see a 1x 10x divide, assuming they hire well. In those that don't, those that only want work done and don't particularly care? That's where the dichotomy presents itself. There is nothing inherently wrong with either group. Work gets paid, you don't have to be a magical 10x engineer to be worth the salary. And there's no shame in coding as a job instead of as a hobby.
- CobrastanJorji 4y ago
  "Hiring well" or hiring "the best" isn't a panacea. People change. Before I had kids, I was working hard, working late nights, and some of my work was all-consuming. After, I've definitely had periods where my main focus was on showing up to meetings and making sure I got at least pretty okay on my performance reviews, while actually focusing on, y'know, not work. If the company doesn't punish people for becoming half as productive, a lot of the folks are going to become half as productive, even if they were "the best" at some point. Especially true when morale at a company drops. Canceling projects, being assigned to boring projects (the next year will focus on Sarbanes Oxley compliance, guys!), having your company or work dragged through the news, it adds up, and people get detached.

menor 4y ago

I'm not sure if I'd name them "the politician", because I think they are not doing the harm consciously, but I've met several of them. Pair it with the "CV builder" ,that just throws new technologies at problems to add them to their CVs, and now your codebase is a minefield.

sbf501 4y ago

Since we're being anecdotal: I think that claim is jaded and angry, and makes me wonder what kinds of companies people have worked at. Honestly, I've only encountered this once or twice, and I've been a career engineer since 1989 at places like IBM, Intel, and Microsoft. Dozens of positions and groups, and I've never had to play politics. Maybe I've just worked at "good" companies (irony noted), but in my experience it was less about politics and more about getting shit done, and if you failed to get shit done, you were alerted to that very quickly. If you did get shit done, and got it done well, you got promoted, and were given even more shit to get done. Upper management at those big three had their game tight.

vsareto 4y ago
Just like there are loads of average developers, there are loads of average companies. You can get lucky and work at all great companies in your career. Most of us will not have enough jobs in our lives to get a representative sample. There is also a question of having different standards. Bad companies might just be bad for someone who has access to the top companies, but otherwise great for average workers.
- sbf501 4y ago
  Point taken. My comment is a good example of "tech privilege".
tayo42 4y ago
im actually amazed you never ran into politics at work. you never needed to navigate around egos to get what you want, you do every thing purely on merit, every decision is only technical? my whole career as been filled with stuff like people forcing their pet projects on the company, people hiring their friends and dealing with their in crowd
- sbf501 4y ago
  > you do every thing purely on merit, every decision is only technical? Yeah, honestly. The vast majority of my hard decisions I made were based on schedule and resources: having to kill things or move people around. The only "political" anomaly I witnessed was that it seemed the employees at the Israel Design Center at Intel were getting promoted to principal at a much faster rate, and with much less years and experience, for what didn't seem like actual merit. But that didn't impact me other than some jealousy, because the line for principal promotion in my division(s) were very long with really really smart people. And I've seen many principals get shown the door for poor performance. One possibility is that I never reached a level where politics mattered, or teams were small enough that it didn't have time to foment. And there certainly people who lived to become managers because they thought it was a status symbol, but I was happy for them to do the job. Another could be that I'm just... well, daft. Both are possible. :)

bgro 4y ago

This is almost exclusively what I've encountered in most of the "elite" engineers. It's frustrating because they're the ones saying coding and job hopping is easy. They're the ones in tech interviews who downplay your achievements. In my experience, rather than leaving for another company though, they're often a C-suite favorite and get to start some new project (often it's whatever they want to do as long as it's remotely justifiable). They get it up to 80% complete so they can hand it off to another team to do the last 20%. Since the project is whatever they want to do, they use very unusual languages or design choices that the new team has to pick up and fix. A lot of times it's whatever the big new thing is. (For example, expect statements like this: "Everything is obsolete legacy code now that Electron exists!" "No need to keep this standalone offline test database, setup shell scripts, or maintain the environment setup guide because Docker will automatically solve all of these cases!") They continue getting new projects because these 1 or 2 people "did the project 80% complete in 1 month, and the last 20% is taking the handoff team of five at least 3 months to do." Bonus points when it is expanded from some sort of hackathon, or some fake story about how some person completed the 80% portion over the weekend. In the former, all the connections and APIs are hard-coded and faked for their demo. In the latter, they had actually been working on this for the past couple months instead of doing their assigned work which made their official team look even less productive. I was on the teams always picking up the last 20%, but I got moved onto the 80% team once. I was amazed at how much code I could blow through with time to spare when I didn't have to worry about all the edge cases and minute details. Unfortunately, I got temporarily moved onto a company-wide prod support team which then got cut due to covid. Hooray.

lioeters 4y ago
The story reminds me of the so-called 80/20 rule. > Microsoft noted that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in a given system would be eliminated. Lowell Arthur expressed that "20% of the code has 80% of the errors. Find them, fix them!" More relevant part: > It was also discovered that, in general, 80% of a piece of software can be written in 20% of the total allocated time. Conversely, the hardest 20% of the code takes 80% of the time. https://en.wikipedia.org/wiki/Pareto_principle#In_computing https://en.wikipedia.org/wiki/Pareto_principle#In_computing It sounds like you were often stuck with the toughest 20% which actually took 80% of the effort. I also heard that of that 20%, there's another level of 80/20, where a further 20% takes 80% of the rest of the effort, and so on. Anyway, I hope you find a better situation!

jacobr1 4y ago

There is also the "positive" version of the politician. They have enough technical credibility, social skills, relationships with senior management, to remove organizational log-jams. Other companies might hire a consultant to come and tell them what they already know they need to do (but can't organizationally agree to do) - but with this archetype, you can call them in and they will cut out the bullshit, somehow without upsetting everyone.

hayst4ck 4y ago
I think that description matches the articles "architect" archetype: > The Architect is responsible for the direction, quality and approach within a critical area, both today and stretching into the multi-year future horizon. They combine a deep knowledge of technical constraints, user needs, and organization level leadership. The reason I labeled it politician is because they are primarily using their position for self-gain. A general definition for politics is any time the inequality company > team > self is violated (at least in terms of compensated work). I generally agree with that definition. That is why I used the word politician.
davewritescode 4y ago
I have found myself in this archetype before. Management wanted a feature, went to the architects and got some INSANE estimate that couldn’t be justified by the revenue that would be coming in. Management felt like they were being told to fuck off with crazy estimates and they weren’t completely wrong. I was asked to review the proposal by a VP, came up with some simplifications, presented it back to the same architects and we delivered it for 10% of the anticipated cost and the feature was profitable in year 1. It’s had no defects because it was a simple design. Sometimes you need people who can speak to managers and engineers with credibility to get things done.
- qznc 4y ago
  Most people have a very cynical view of politics and I can emphasize. However, I try to stay more positive about it. Politics, for me, is about making decisions in groups too large to just talk with everyone. In such circumstances “bridge people”, like davewritescode, who can communicate with multiple factions are very valuable for progress. Sadly, especially in large “safe” enterprises people don’t want to learn this. Developers blame managers for “not understanding software” and managers blame developers for “lack of business understanding”.

jameshart 4y ago

There are people who are bad at every job. That doesn’t mean that the people who are hiring people into that role are looking to have someone do it badly. Or that anyone who wants such a role is automatically suspected of having nefarious motives. These role archetypes are descriptions of realistic, reasonable expectations for high level IC roles. It’s a useful, positive contribution that will help engineering directors and senior coders better negotiate clearly defined roles and responsibilities. It’s just not constructive to say ‘but yeah, sometimes when you employ someone at this level and you don’t clarify the role or hold them accountable, they do terrible things and it enables charlatans to prosper!’ Sure, of course it does. But this article is a useful and constructive model for helping prevent that from happening. What you frame as an addition to the article actually represents a cynical undermining of its entire value. I think that’s a sad way to engage.

woah 4y ago

Their crappy code might be generating millions of dollars in revenue while you fix it and curse their name

hayst4ck 4y ago
True! But it might also grind the company's ability to release features to a halt creating a stagnant stock price and an underwhelming IPO because they chose to avoid the hard work of migrating, refactoring, and simplifying, or setting a culture of maintainable code preferring more easily marketable (and probably more fun and less failure prone) feature work that also looks much better on a resume.
- scarface74 4y ago
  Counterexample: Twitter. Every indication is that the code base was horrible. They found product market fit, got funding and went public. Amazon codebase was also famously barely held together by duct tape for the first few years
  - hayst4ck 4y ago
    I'm not trying to say that you can't incur technical debt if you pay it off. What I am trying to say is that a culture of technical debt stagnates growth. I would point to twitter as an example of the point I was trying to make, so I don't think it's a very good counter example: 11/07/2013 $44.9 117,633,000 $45.1 $50.09 $44 10/06/2022 $49.39 68,511,080 $50.98 $51.55 $49.29 Practically no sustained growth in almost a decade. Poor code and operations hampers the ability to prototype new features and destroys innovation.
    - icedchai 4y ago
      Yes, Twitter's stock has basically gone nowhere, just like its product. (I'm a TWTR bag holder. Hoping to get a pay out from Musk soon!)
    - scarface74 4y ago

Aeolun 4y ago

How does that work exactly? I can absolutely commit an unmaintainable mess directly to master, but I’d be very quickly called out by my team.

hayst4ck 4y ago
Very large portions of some very major companies have <4 years work experience. Couple that with incredibly large engineer to management ratios and that inexperienced devs are often placed under more experienced ones, and the ability to call out unmaintainable code starts to diminish. A lot of these prolific devs will not see the code base complexity for the "tragedy of the commons" it is, and bemoan the people and teams who start to try adding "regulations" (meetings/code review) to protect the common because it slows down their ability to meet their management given goals. There is also a magic phrase that frequently disarms attempts to prevent bad code from entering a code base "this is just temporary." It's easy to put off fixing the "temporary" code forever as other things become higher priority. Often times someone will inherit a staff engineer's code and therefore won't have been able to stop it. Sometimes staff engineers are able to create an entire service with minimal review that is then "gifted" to a team to refine and maintain. In a lot of these situations, the feedback mechanisms (yearly peer review) will limit who can give feedback about who, not to mention they are not anonymous and staff engineers are usually highly connected.
dilyevsky 4y ago
Easy - you rope other engineers in to work on the implementation. Then if it works out you claim the credit, if not either scrap the project due to “change of direction/reprioritization” or throw them under the bus.
a_puppy 4y ago
It works because management is bought into the politician's bullshit. So if another team member tries to call it out, then the manager labels the other team member as "hard to work with" (https://lethain.com/hard-to-work-with/ https://lethain.com/hard-to-work-with/) instead of holding the politician accountable.

29athrowaway 4y ago

Example: Dennis Nedry Prior experience: Solution architect at Jurassic Park. Present: Dinosaur food

didip 4y ago

The politician is totally a thing at large FAANG companies! It took a while for people to figure out their BS and when it's finally unearthed, two years has passed and they are ready to move on to another team or company and repeat the cycle. Sometimes they even get a promo before their rube goldberg machinery is finished and someone else had to take the fall.

scarface74 4y ago
You have to be a politician at a tech companies. Your promo docs depend on it. How can you show “scope” or “cross team impact” without some amount of politicking?

Olreich 4y ago

> They lay operational traps everywhere in their quest to get things done fast (like directly embedding config data in code to avoid fixing the config format). Specific to your example, rather than the sentiment, I think embedding config in code is highly valuable when you don't have a lengthy deployment cycle and have direct access to the source. It gives your compiler more information which can help prevent bad configurations (which are the cause of failures more often than anything else from what I've seen). Developers also have a better shot at feeling how badly configurable a particular component is when the configuration is code. It's much easier to hide the overly-configurable systems under a rug when the configuration is far away from implementation, in a DSL, in a different repository, or only visible at deployment.

acedTrex 4y ago
I agree, configs in code are not a bad thing necessarily if they don't change often or at all. Sprawling config files are a significantly higher challenge to get your bearing with.
- FranGro78 4y ago
  I’ve been trying unsuccessfully to get buy in on config as code. Instead we have property / yaml files, read into anaemic “classes” which do not perform validation themselves. Validation duties are also foisted onto other parts of the system. Stacked onto that we sometimes have file name based convention for defining a hierarchy of configs, to save on repetition between environments.
  - hayst4ck 4y ago
    Config as code is fine as long as it results in a fully realized config that is then consumed by other code. All the big companies have almost certainly done it. I would make sure when implementing it you have someone who is very opinionated review all configs to ensure that the same behavior is always implemented in the same way until a linter can enforce idioms. I would avoid explicit conditionals and explicit loops, instead relying on implied conditionals and implied loops. I would absolutely not use any "live" data, meaning the code should be relatively pure without any dependencies. Pystachio is not a bad choice in python land: https://github.com/wickman/pystachio https://github.com/wickman/pystachio

spaetzleesser 4y ago

This describes the “enterprise architects” at my company. They read a few white papers, make nice PowerPoints, send the work to some offshoring company. The systems produced either don’t work or have serious problems but in the meantime they have already moved into another project and leave cleaning up the mess to other people.

dimgl 4y ago

This is 100% accurate. In fact, I think I've met a couple during my career.

TheDudeMan 4y ago

What is the difference between code and config, other than one is well-typed?

hayst4ck 4y ago
Config could be put into a database and queried while code doesn't have a sensical database representation. Even when config is code (which is almost guaranteed to happen as a config requiring system is developed), at some point in the process there is a representation that could be meaningfully stored in a columnar database before it's consumption. Code is generally considered stateless, asking for an input and providing an output that is determined only by the code and the input. Embedding state inside of code is generally a pretty grievous sin, although some places are vastly more sinful than others.

gorgoiler 4y ago

That’s a great technical example. How many times have you encountered an engineer who wraps up their tool’s interface and exposes its functionality through a YAML config file when really it should have just been left as a programmatic interface? The hubris of the engineer is in believing they’ve thought of everything anyone could ever want to do with their tool. Imagine if a shell only let you set your PATH via a static config file filled with strings. It’s probably fine 99% of the time but at some point someone somewhere is going to start programmatically building paths.yaml. Yuck.

michaelcampbell 4y ago

I'd wager the "product manager" equivalent of this is even more widespread. They constantly disallow tech debt sprints or work to happen, in order to get that nifty new feature out the door quickly in and will tackle the cut corners and tech debt "later, after MVP" or somesuch nonsense. Then by the time that debt must be paid, they're off to another team|org|project. I've seen it way too many times.