5 ms·

I guess you've never met a competent generalist, then, which is funny because that's exactly who you need as your first employee.

derfabianpeter 4y ago
Funny part is that „competent generalists“ (those Brent-style types) are very rare and most technology needs to be designed for incompetent specialists. Also funny is that these generalists typically build as if everyone has their own skillset which renders many systems unusable once Brent has left the building.
- manigandham 4y ago
  They're not just rare, the bigger problem is that most companies don't know how to deal with them. They either can't pay for them, don't give them enough freedom, weigh them down in a big team, or any number of other issues. One person in a specific role (even if they're not very good at it) is far easier for most organizations to deal with than the 10x generalist that can get things done. It can work well in very early startups, but there's limited reward there for it to be worth it.
- DeathArrow 4y ago
  >those Brent-style types Which Brent are you talking about?
  - TedDoesntTalk 4y ago
    I get the sense the name is being used in a general way like a “Karen”, but I’ve never heard of a “Brent”.
    - mwarkentin 4y ago
      From The Phoenix Project: https://allengeer.com/how-to-handle-brent-in-the-phoenix-project/ https://allengeer.com/how-to-handle-brent-in-the-phoenix-pro...
    - arch-ninja 4y ago
      Brent is the engineer building all the real tech that a company in the Phoenix Project is building, and when the MC (a manager, Bill I believe) realizes this he re-directs resources so Brent can do his job without interruptions, ultimately saving the company. Excellent read, it's the first book managers are told to read when they use SCRUM/AGILE incorrectly.
- TameAntelope 4y ago
  Nobody cares if what you built is sustainable and scalable if you can't do it fast enough to get your first customers, and there is plenty of time to make what you've built usable by the time you've left. If you, as a founder, hire an incompetent specialist as your first employee, maybe you don't deserve to be successful. Your first hire is either a "Brent", or you have to get very lucky in just about every way.
KronisLV 4y ago
Expecting someone who's capable of handling most roles isn't always a viable strategy. Personally, I consider myself such a person and I've been called in numerous times when people: - need to use Kubernetes because of project requirements, but all they have is a single node with 8 GB of RAM (K3s sufficed nicely) - need to deliver OCI images and Helm charts, yet have no idea how to handle all of the infra aspects here (Nexus to the rescue) - need to containerize any number of applications from old timey monoliths that ran in loosely defined Tomcat and JDK versions, badly - need to figure out why their apps run badly, despite there being almost no logs ("Log output is spammy!" they say), no APM ("What?") or proper monitoring for whatever they've written - need to figure out how container networking works and why them attempting to use localhost for inter-service communication isn't always the best idea - need to figure out how to manage configuration properly, especially in situations where they add some random configuration parameter 4 months back, forget about it and then attempt to ask me about what it means, because of course they didn't document it - need to set up log rotation, because they absolutely refuse to use log shipping and see no benefit in it, yet don't want to delete the old logs whilst wanting to be able to view the old ones, yet don't know how to configure compression for the older ones and thus run out of disk space on the server - need to set up a reverse proxy and manage its configuration, because all they know is Apache/httpd (which I think is a nice project), but haven't bothered learning Nginx which they now need to use because of said requirements - need help with their supposedly automatic database migrations actually failing because they failed to account for pre-existing data - need help with the project moving ahead at a snail's pace because they wanted to pad their CVs and picked Tailwind CSS instead of some pre-made component library and thus have to reinvent the wheel, as well as use TypeScript which they do not know how to use and are slow with as a result Somehow such generalists feel few and far between, so relying on them to always be there to save you from yourself won't be reliable. Furthermore, there will be lots of people with either limited knowledge or limited interest in learning new things. I've see someone say that "restarting services is not in my job description" when asked to restart some environment. Many out there will also be perfectly fine with writing apps like they had 20 years ago, without taking advantage of any of the benefits of 12 Factor Apps or similar principles. They will also reach for the local file system instead of something like S3 for object storage and application memory instead of using Redis for session storage. They will seldom be able to write apps that are horizontally scalable and as a consequence you'll have to rely upon a single monolith which should always be up and working, which, given their lack of ability to write proper unit tests, will rarely work out that way. Unless you are very selective in your hiring, plan for people like that also being present.
Gordonjcp 4y ago
I grew up on a farm, so I've got a very generalist attitude to things for the simple reason that if the thing breaks you have to take the covers off and fix it, or you get to walk home in the rain. And then, tomorrow, you get to walk back out to it in the rain and fix it anyway. I've used a microscope, a JTAG cable and a MIG welder on the same project on the same day. Here's the thing though - I like simplicity. I like stuff to be simple. I drive a 25-year-old Range Rover because it's simple, and because if it breaks I can fix it quickly with simple tools. I bring this simplicity to the stuff I build - lowest parts count, easiest to get parts, comprehensive manual. Build your software stack as though you expect to have to fix it in a boggy field on a pissing wet Sunday afternoon with a hammer and a roll of sticky tape, because that's exactly what you're going to have to do.
- rtp4me 4y ago
  Totally agree about keeping things simple. When [it] hits the fan on Sunday afternoon, you can probably root-cause the issue fairly quickly and get things running again. And, you don't have to wait for that *one guy* who went on vacation Friday to come back a week later to show you how things were configured.
  - Gordonjcp 4y ago
    Exactly. A "perfect" fix next week is not better than "drive it gently and bring it back on Monday so I can look at it properly".
- geertj 4y ago
  My style as well. I would add one thing which I call “critical dimension analysis.” Try to identify the main customer driver for the domain you’re in (could be cost/performance/something entirely different), and invest at little more in that technical area (while still keeping things relatively simple). That will give you a simple yet efficient stack for the domain you’re in, which will be a great base for taking your product forward.

derfabianpeter 4y ago

Funny part is that „competent generalists“ (those Brent-style types) are very rare and most technology needs to be designed for incompetent specialists. Also funny is that these generalists typically build as if everyone has their own skillset which renders many systems unusable once Brent has left the building.

manigandham 4y ago
They're not just rare, the bigger problem is that most companies don't know how to deal with them. They either can't pay for them, don't give them enough freedom, weigh them down in a big team, or any number of other issues. One person in a specific role (even if they're not very good at it) is far easier for most organizations to deal with than the 10x generalist that can get things done. It can work well in very early startups, but there's limited reward there for it to be worth it.
DeathArrow 4y ago
>those Brent-style types Which Brent are you talking about?
- TedDoesntTalk 4y ago
  I get the sense the name is being used in a general way like a “Karen”, but I’ve never heard of a “Brent”.
  - mwarkentin 4y ago
    From The Phoenix Project: https://allengeer.com/how-to-handle-brent-in-the-phoenix-project/ https://allengeer.com/how-to-handle-brent-in-the-phoenix-pro...
  - arch-ninja 4y ago
    Brent is the engineer building all the real tech that a company in the Phoenix Project is building, and when the MC (a manager, Bill I believe) realizes this he re-directs resources so Brent can do his job without interruptions, ultimately saving the company. Excellent read, it's the first book managers are told to read when they use SCRUM/AGILE incorrectly.
TameAntelope 4y ago
Nobody cares if what you built is sustainable and scalable if you can't do it fast enough to get your first customers, and there is plenty of time to make what you've built usable by the time you've left. If you, as a founder, hire an incompetent specialist as your first employee, maybe you don't deserve to be successful. Your first hire is either a "Brent", or you have to get very lucky in just about every way.

KronisLV 4y ago

Expecting someone who's capable of handling most roles isn't always a viable strategy. Personally, I consider myself such a person and I've been called in numerous times when people: - need to use Kubernetes because of project requirements, but all they have is a single node with 8 GB of RAM (K3s sufficed nicely) - need to deliver OCI images and Helm charts, yet have no idea how to handle all of the infra aspects here (Nexus to the rescue) - need to containerize any number of applications from old timey monoliths that ran in loosely defined Tomcat and JDK versions, badly - need to figure out why their apps run badly, despite there being almost no logs ("Log output is spammy!" they say), no APM ("What?") or proper monitoring for whatever they've written - need to figure out how container networking works and why them attempting to use localhost for inter-service communication isn't always the best idea - need to figure out how to manage configuration properly, especially in situations where they add some random configuration parameter 4 months back, forget about it and then attempt to ask me about what it means, because of course they didn't document it - need to set up log rotation, because they absolutely refuse to use log shipping and see no benefit in it, yet don't want to delete the old logs whilst wanting to be able to view the old ones, yet don't know how to configure compression for the older ones and thus run out of disk space on the server - need to set up a reverse proxy and manage its configuration, because all they know is Apache/httpd (which I think is a nice project), but haven't bothered learning Nginx which they now need to use because of said requirements - need help with their supposedly automatic database migrations actually failing because they failed to account for pre-existing data - need help with the project moving ahead at a snail's pace because they wanted to pad their CVs and picked Tailwind CSS instead of some pre-made component library and thus have to reinvent the wheel, as well as use TypeScript which they do not know how to use and are slow with as a result Somehow such generalists feel few and far between, so relying on them to always be there to save you from yourself won't be reliable. Furthermore, there will be lots of people with either limited knowledge or limited interest in learning new things. I've see someone say that "restarting services is not in my job description" when asked to restart some environment. Many out there will also be perfectly fine with writing apps like they had 20 years ago, without taking advantage of any of the benefits of 12 Factor Apps or similar principles. They will also reach for the local file system instead of something like S3 for object storage and application memory instead of using Redis for session storage. They will seldom be able to write apps that are horizontally scalable and as a consequence you'll have to rely upon a single monolith which should always be up and working, which, given their lack of ability to write proper unit tests, will rarely work out that way. Unless you are very selective in your hiring, plan for people like that also being present.

Gordonjcp 4y ago

I grew up on a farm, so I've got a very generalist attitude to things for the simple reason that if the thing breaks you have to take the covers off and fix it, or you get to walk home in the rain. And then, tomorrow, you get to walk back out to it in the rain and fix it anyway. I've used a microscope, a JTAG cable and a MIG welder on the same project on the same day. Here's the thing though - I like simplicity. I like stuff to be simple. I drive a 25-year-old Range Rover because it's simple, and because if it breaks I can fix it quickly with simple tools. I bring this simplicity to the stuff I build - lowest parts count, easiest to get parts, comprehensive manual. Build your software stack as though you expect to have to fix it in a boggy field on a pissing wet Sunday afternoon with a hammer and a roll of sticky tape, because that's exactly what you're going to have to do.

rtp4me 4y ago
Totally agree about keeping things simple. When [it] hits the fan on Sunday afternoon, you can probably root-cause the issue fairly quickly and get things running again. And, you don't have to wait for that *one guy* who went on vacation Friday to come back a week later to show you how things were configured.
- Gordonjcp 4y ago
  Exactly. A "perfect" fix next week is not better than "drive it gently and bring it back on Monday so I can look at it properly".
geertj 4y ago
My style as well. I would add one thing which I call “critical dimension analysis.” Try to identify the main customer driver for the domain you’re in (could be cost/performance/something entirely different), and invest at little more in that technical area (while still keeping things relatively simple). That will give you a simple yet efficient stack for the domain you’re in, which will be a great base for taking your product forward.