7 ms·

This is what I constantly tell my students: The hard part about doing a tech product for the most part isn't the what beginners think makes tech hard — the hard

by atoav 3y ago

This is what I constantly tell my students: The hard part about doing a tech product for the most part isn't the what beginners think makes tech hard — the hard part is wrangling systemic complexity in a good, sustainable and reliable way. Many non-tech people e.g. look at programmers and think the hard part is knowing what this garble of weird text means. But this is the easy part. And if you are a person who would think it is hard, you probably don't know about all the demons out there that will come to haunt you if you don't build a foundation that helps you actively keeping them away.

sonicanatidae 3y ago
>This is what I constantly tell my students: The hard part about doing a tech >product for the most part isn't the what beginners think makes tech hard — the >hard part is wrangling systemic complexity in a good, sustainable and reliable >way. I teach the same thing, seemingly every day to my teams. It doesn't work, until it works reliably, within reason. High-5 from the doers to the teachers! (Both are needed) For the record, my partner teaches at a major university, just not tech. ;)
sebmellen 3y ago
More people need to read https://grugbrain.dev/ https://grugbrain.dev/
- jeremyjh 3y ago
  I really wish I'd read this 25 years ago, but probably I wouldn't have believed any of it.
  - sebmellen 3y ago
    In some way, building absurdly complex systems and watching them fail is a rite of passage.
    - Arson9416 3y ago
      Fortunately (unfortunately?) most places are in some stage of that process, so it's easy enough to participate in.
  - gedy 3y ago
    I don’t know, I’ve mostly followed this approach over my 20 year career, but it really depends on your surroundings, and honestly hasn’t led to great success. E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined. There’s also plenty of companies who don’t want engineers getting involved with decisions, and product and UX people work upfront and in isolation until you’re handed tiny Jira tickets with Figma mockups attached. Discussion at that point is considered “disruptive“. It honestly seems like this has gotten worse in the past 5 to 10 years.
    - sebmellen 3y ago
      > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer > sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice > but grug must to grug be true, and "no" is magic grug word. Hard say at first, especially if you nice grug and don't like disappoint people (many such grugs!) but easier over time even though shiney rock pile not as high as might otherwise be > is ok: how many shiney rock grug really need anyway?
    - Karrot_Kream 3y ago
      > E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined. I'm amazed at how non-obvious this seems to most engineers and how often this angst gets repeated in online tech communities. I mean, when I was in academia there was a tension between publishing impactful results or cozying up with the right professors into the right conferences vs outputting meaningful work (pressures into p-hacking or having big names author suspicious results is par for the course.) In industry it's the tension between product folks and engineers. Have you ever talked to high-level finance folks who deal with the tension of product folks just wanting to do things and finance folks who remind them how money works? It turns out that the hardest thing about getting things done with people is... dealing with people. I wish there was a way to remove this weird somewhat-ascetic blockage found in tech communities about this. Many of the more physical engineering occupations have to deal with this in the form of contractors and supervisors. Wait until you have to work on a government contract lol. When I mentor junior engineers with these feelings, I like to use an adage: "Where there are people there are politics." Look at pretty much any prominent FOSS project and you'll see tons of it (by dint of transparency) and those folks generally focus on the project and not a product!
- TurkishPoptart 3y ago
  I like this but I don't understand one part under "Saying OK" *sometimes probably best just not tell project manager and do it 80/20 way.* Does 80/20 in this context mean that we'll implement 80% of what is asked for an leave out the remaining complex parts?
  - sebmellen 3y ago
    Kind of, and it usually works. Even as a founder you can trick yourself into doing things that way. I've found that 20/80, Pareto style, is even better. 20% of the features can achieve 80% of the sales, and you'll be a lot happier if you're not constantly chasing the long tail.
  - bcrosby95 3y ago
    80% of the features/details for 20% of the code/complexity. Even minor tweaks can have an outsized effect on the final code. A large part of my job is doing this in such a way that satisfies the stakeholders.
  - internet101010 3y ago
    More or less and it usually gets the job done. The last 20% can be a real time suck if it isn't managed properly. What you don't want is for the last 20% to occupy 80% of the time.
  - jacquesm 3y ago
    You do 80% of the functionality with 20% of the required code and pretend that this is what the project manager asked for. Likely they'll never notice the missing bits which may have seemed like a good idea at the time .If they insist you do 80% of what remains with another 20% of the code. But with some luck your project managers' butterfly mind will have flitted on to greener pastures and everybody is happy. No need for Grug to reach for his club (while remaining calm).
- airstrike 3y ago
  LMAO that's hilarious, thanks for sharing > best weapon against complexity spirit demon is magic word: "no" > "no, grug not build that feature" > "no, grug not build that abstraction" > "no, grug not put water on body every day or drink less black think juice you stop repeat ask now" > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer
  - moffkalast 3y ago
    > sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice Perfection
- oooyay 3y ago
  This is some really beautiful prose
- jacquesm 3y ago
  It's priceless. I figure most programmers at some point during their career will be able to relate to having a Grug Brain. complexity very, very bad! This site has more knowledge condensed in one page than a stack of randomly assorted books on software development do.
alfalfasprout 3y ago
I mean, this is largely true in software engineering in general. Programming is easy. Perhaps being an excellent programmer is much harder but for many things being mediocre is good enough. The hard part is building things sustainably at scale (people wise or performance wise). That's when a combination of knowing how to manage systemic complexity and knowing how to communicate very well (soft skills) really come into play.
- bcrosby95 3y ago
  IMHO the hard part with a startup is you don't want to build something that works sustainably at scale. You want to build something that could plausibly morph into something that is sustainable at scale.
  - mgaunard 3y ago
    Depends on the stage of the startup lifecycle you're at. But in general, reaching profitability (which is the real hard part) will require making scaling efficient and operations smooth.
  - gopher_space 3y ago
    I've started to look at scaling like you're killing a golden-egg-laying goose but there's a 1 in n chance that it'll pay off for you. n starts higher than you'd hope and rises as you make tradeoffs. I've been thinking about scaling a bit because I've been digging into a large SaaS product for a client and find I am able to replicate their locally relevant output at a fraction of the cost. Scaling up has allowed this SaaS to serve an entire country but a majority of their user base think in terms of one or two local counties. Consuming their output means subsidizing work they do that's irrelevant to (or might actually compete with) your own interests.
- JumpCrisscross 3y ago
  There is a weird local optimisation problem where being an excellent programmer can make one a bad software engineer. (Another: unparalleledly excellent Excel skills making one a worse financier.)
j45 3y ago
The business degree kids with an idea need to realize the tech cofounders can learn and understand business. Having an idea is like having a thought. A startup needs product and distribution. If a tech cofounder builds what’s asked of him and the sales cofounder can’t sell, should the ownership revert to the tech cofounder?
simonw 3y ago
I love the way you put this. It also doubles as a great explanation for why programmers shouldn't be worried that ChatGPT is going to steal their jobs: ChatGPT is good at the garble of weird text, but it's terrible at the "wrangling systemic complexity in a good, sustainable and reliable way" piece.
- ianlevesque 3y ago
  I think ChatGPT will eventually be good at the garble of weird text. It's immensely helpful already but you really must be checking up on what it is telling you. Plausible but non-existent or incorrectly used APIs are routine still. I definitely bet on it eventually getting there though.
- FuckButtons 3y ago
  You know what computers couldn’t do 10 years ago? Understand and write coherent code. Why do you feel confident in your opinion that they won’t be able to do that in the next 10 years?
  - dijit 3y ago
    1) an understanding of what LLMs can actually do 2) a strong history of understanding the limits of functional automation (why are there still project managers? Asana exists!) 3) an understanding that progress will slow in this space considerably once we have made the big wins and the hype cycle dies down. (see also; every tech hype cycle)
    - travisjungroth 3y ago
      I go the exact opposite way on number 3. It seems more likely to me this follows the growth trend of the internet, mobile phones and computer graphics than blockchain and VR. 10 more year of growth like the last would be pretty wild to experience.
  - simonw 3y ago
    If they can "wrangle systemic complexity in a good, sustainable and reliable way" then I think that's AGI. If we hit AGI we'll have plenty of other things to worry about beyond being able to make a living as programmers.
willsmith72 3y ago
depends on what part of "doing a tech product" you're talking about > the hard part is wrangling systemic complexity in a good, sustainable and reliable way in an early startup, this thinking is one of the most common ways to failure. people optimise their technology for its scalability, reliability, and "cleanliness", when none of that matters yet. all that matters is finding product market fit
jofla_net 3y ago
An idiot admires complexity, a genius admires simplicity. --TAD
- HaZeust 3y ago
  He was so great at compsci, that wasn't even his hardest question in programming!
koonsolo 3y ago
I would say the tech is the easy part. The most difficult part is getting customers.
corry 3y ago
To rephrase your point with tongue-firmly-in-cheek: "many technical people look at products and think the hard part is wrangling systemic complexity in a good, sustainable and reliable way" but in reality, that's not the hard part. If your product is successful enough that systemic complexity is your chief problem, congratulations, you've made it further than most startups - which die from lack of demand, lack of paying customers, and lack of users giving feedback.
RobKohr 3y ago
Great comment! I am dropping that as a quote on my blog as others need to read this.

by atoav 3y ago

sonicanatidae 3y ago

>This is what I constantly tell my students: The hard part about doing a tech >product for the most part isn't the what beginners think makes tech hard — the >hard part is wrangling systemic complexity in a good, sustainable and reliable >way. I teach the same thing, seemingly every day to my teams. It doesn't work, until it works reliably, within reason. High-5 from the doers to the teachers! (Both are needed) For the record, my partner teaches at a major university, just not tech. ;)

sebmellen 3y ago

More people need to read https://grugbrain.dev/ https://grugbrain.dev/

jeremyjh 3y ago
I really wish I'd read this 25 years ago, but probably I wouldn't have believed any of it.
- sebmellen 3y ago
  In some way, building absurdly complex systems and watching them fail is a rite of passage.
  - Arson9416 3y ago
    Fortunately (unfortunately?) most places are in some stage of that process, so it's easy enough to participate in.
- gedy 3y ago
  I don’t know, I’ve mostly followed this approach over my 20 year career, but it really depends on your surroundings, and honestly hasn’t led to great success. E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined. There’s also plenty of companies who don’t want engineers getting involved with decisions, and product and UX people work upfront and in isolation until you’re handed tiny Jira tickets with Figma mockups attached. Discussion at that point is considered “disruptive“. It honestly seems like this has gotten worse in the past 5 to 10 years.
  - sebmellen 3y ago
    > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer > sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice > but grug must to grug be true, and "no" is magic grug word. Hard say at first, especially if you nice grug and don't like disappoint people (many such grugs!) but easier over time even though shiney rock pile not as high as might otherwise be > is ok: how many shiney rock grug really need anyway?
  - Karrot_Kream 3y ago
    > E.g. If you’re surrounded by yes men who will code whatever without question, product people greatly prefer that, and you end up sidelined. I'm amazed at how non-obvious this seems to most engineers and how often this angst gets repeated in online tech communities. I mean, when I was in academia there was a tension between publishing impactful results or cozying up with the right professors into the right conferences vs outputting meaningful work (pressures into p-hacking or having big names author suspicious results is par for the course.) In industry it's the tension between product folks and engineers. Have you ever talked to high-level finance folks who deal with the tension of product folks just wanting to do things and finance folks who remind them how money works? It turns out that the hardest thing about getting things done with people is... dealing with people. I wish there was a way to remove this weird somewhat-ascetic blockage found in tech communities about this. Many of the more physical engineering occupations have to deal with this in the form of contractors and supervisors. Wait until you have to work on a government contract lol. When I mentor junior engineers with these feelings, I like to use an adage: "Where there are people there are politics." Look at pretty much any prominent FOSS project and you'll see tons of it (by dint of transparency) and those folks generally focus on the project and not a product!
TurkishPoptart 3y ago
I like this but I don't understand one part under "Saying OK" *sometimes probably best just not tell project manager and do it 80/20 way.* Does 80/20 in this context mean that we'll implement 80% of what is asked for an leave out the remaining complex parts?
- sebmellen 3y ago
  Kind of, and it usually works. Even as a founder you can trick yourself into doing things that way. I've found that 20/80, Pareto style, is even better. 20% of the features can achieve 80% of the sales, and you'll be a lot happier if you're not constantly chasing the long tail.
- bcrosby95 3y ago
  80% of the features/details for 20% of the code/complexity. Even minor tweaks can have an outsized effect on the final code. A large part of my job is doing this in such a way that satisfies the stakeholders.
- internet101010 3y ago
  More or less and it usually gets the job done. The last 20% can be a real time suck if it isn't managed properly. What you don't want is for the last 20% to occupy 80% of the time.
- jacquesm 3y ago
  You do 80% of the functionality with 20% of the required code and pretend that this is what the project manager asked for. Likely they'll never notice the missing bits which may have seemed like a good idea at the time .If they insist you do 80% of what remains with another 20% of the code. But with some luck your project managers' butterfly mind will have flitted on to greener pastures and everybody is happy. No need for Grug to reach for his club (while remaining calm).
airstrike 3y ago
LMAO that's hilarious, thanks for sharing > best weapon against complexity spirit demon is magic word: "no" > "no, grug not build that feature" > "no, grug not build that abstraction" > "no, grug not put water on body every day or drink less black think juice you stop repeat ask now" > note, this good engineering advice but bad career advice: "yes" is magic word for more shiney rock and put in charge of large tribe of developer
- moffkalast 3y ago
  > sad but true: learn "yes" then learn blame other grugs when fail, ideal career advice Perfection
oooyay 3y ago
This is some really beautiful prose
jacquesm 3y ago
It's priceless. I figure most programmers at some point during their career will be able to relate to having a Grug Brain. complexity very, very bad! This site has more knowledge condensed in one page than a stack of randomly assorted books on software development do.

alfalfasprout 3y ago

I mean, this is largely true in software engineering in general. Programming is easy. Perhaps being an excellent programmer is much harder but for many things being mediocre is good enough. The hard part is building things sustainably at scale (people wise or performance wise). That's when a combination of knowing how to manage systemic complexity and knowing how to communicate very well (soft skills) really come into play.

bcrosby95 3y ago
IMHO the hard part with a startup is you don't want to build something that works sustainably at scale. You want to build something that could plausibly morph into something that is sustainable at scale.
- mgaunard 3y ago
  Depends on the stage of the startup lifecycle you're at. But in general, reaching profitability (which is the real hard part) will require making scaling efficient and operations smooth.
- gopher_space 3y ago
  I've started to look at scaling like you're killing a golden-egg-laying goose but there's a 1 in n chance that it'll pay off for you. n starts higher than you'd hope and rises as you make tradeoffs. I've been thinking about scaling a bit because I've been digging into a large SaaS product for a client and find I am able to replicate their locally relevant output at a fraction of the cost. Scaling up has allowed this SaaS to serve an entire country but a majority of their user base think in terms of one or two local counties. Consuming their output means subsidizing work they do that's irrelevant to (or might actually compete with) your own interests.
JumpCrisscross 3y ago
There is a weird local optimisation problem where being an excellent programmer can make one a bad software engineer. (Another: unparalleledly excellent Excel skills making one a worse financier.)

j45 3y ago

The business degree kids with an idea need to realize the tech cofounders can learn and understand business. Having an idea is like having a thought. A startup needs product and distribution. If a tech cofounder builds what’s asked of him and the sales cofounder can’t sell, should the ownership revert to the tech cofounder?

simonw 3y ago

I love the way you put this. It also doubles as a great explanation for why programmers shouldn't be worried that ChatGPT is going to steal their jobs: ChatGPT is good at the garble of weird text, but it's terrible at the "wrangling systemic complexity in a good, sustainable and reliable way" piece.

ianlevesque 3y ago
I think ChatGPT will eventually be good at the garble of weird text. It's immensely helpful already but you really must be checking up on what it is telling you. Plausible but non-existent or incorrectly used APIs are routine still. I definitely bet on it eventually getting there though.
FuckButtons 3y ago
You know what computers couldn’t do 10 years ago? Understand and write coherent code. Why do you feel confident in your opinion that they won’t be able to do that in the next 10 years?
- dijit 3y ago
  1) an understanding of what LLMs can actually do 2) a strong history of understanding the limits of functional automation (why are there still project managers? Asana exists!) 3) an understanding that progress will slow in this space considerably once we have made the big wins and the hype cycle dies down. (see also; every tech hype cycle)
  - travisjungroth 3y ago
    I go the exact opposite way on number 3. It seems more likely to me this follows the growth trend of the internet, mobile phones and computer graphics than blockchain and VR. 10 more year of growth like the last would be pretty wild to experience.
- simonw 3y ago
  If they can "wrangle systemic complexity in a good, sustainable and reliable way" then I think that's AGI. If we hit AGI we'll have plenty of other things to worry about beyond being able to make a living as programmers.

willsmith72 3y ago

depends on what part of "doing a tech product" you're talking about > the hard part is wrangling systemic complexity in a good, sustainable and reliable way in an early startup, this thinking is one of the most common ways to failure. people optimise their technology for its scalability, reliability, and "cleanliness", when none of that matters yet. all that matters is finding product market fit

jofla_net 3y ago

An idiot admires complexity, a genius admires simplicity. --TAD

HaZeust 3y ago
He was so great at compsci, that wasn't even his hardest question in programming!

koonsolo 3y ago

I would say the tech is the easy part. The most difficult part is getting customers.

corry 3y ago

To rephrase your point with tongue-firmly-in-cheek: "many technical people look at products and think the hard part is wrangling systemic complexity in a good, sustainable and reliable way" but in reality, that's not the hard part. If your product is successful enough that systemic complexity is your chief problem, congratulations, you've made it further than most startups - which die from lack of demand, lack of paying customers, and lack of users giving feedback.

RobKohr 3y ago

Great comment! I am dropping that as a quote on my blog as others need to read this.