4 ms·

There are plenty of devs who do nothing beyond taking a Jira ticket scoped by others, implementing it, and then grabbing the next ticket. While they may not ha

There are plenty of devs who do nothing beyond taking a Jira ticket scoped by others, implementing it, and then grabbing the next ticket. While they may not have been very successful, they did have a place.

verelo 9mo ago
You’re right but i have always preferred people who can do a little more. Nothing against the socially awkward and conflict avoidant nature in many of these friends, but people who push back and fight to communicate their views and passions often got our team better outcomes than someone who just turns up and does the work they’re asked to do.
- PunchyHamster 9mo ago
  As long as it is not opposite set of skills (talks a lot without knowledge to back it up so essentially using charisma to convince people to do the wrong thing most of the time) then yes, a lil bit of negotiation can save you a whole lot of work in the long run (XY problems being one example)
  - verelo 9mo ago
    For sure, I’ve been tricked into hiring those people before too. It’s good that there’s still something hard in running an organization, the whole “what is value?” question feels like it’ll be one of the few things we have to maintain work for humans over the next little while.
miav 9mo ago
Is this genuinely common? I’ve only ever seen that level of hand holding extended to new grad hires.
- kube-system 9mo ago
  It definitely happens at bloated organizations that aren’t really good at software development. I think it is especially more common in organizations where software is a cost center and business rules involve a specialized discipline that software developers wouldn’t typically have expertise in.
- veyh 9mo ago
  I have 13 years of professional experience, and I work in a small company (15 people). Apart from one or two weekly meetings, I mostly just work on stuff independently. I'm the solo developer for a number of projects ranging from embedded microcontrollers to distributed backend systems. There's very little handholding; it's more like requirements come in, and results come out. I have been part of some social circles before but they were always centered around a common activity like a game, and once that activity went away, so did those connections. As I started working on side hustles, it occurred to me that not having any kind of social network (not even social media accounts) may have added an additional level of difficulty. I am still working on the side hustles, though.
  - nuancebydefault 9mo ago
    > it's more like requirements come in, and results come out. Wow someone is very good at setting requirements. I have never seen that in 25 years of dev life.
    - veyh 9mo ago
      Of course, sometimes people realize that what they asked for wasn't actually what was needed.
      - pmg101 9mo ago
        I mean... This "realization" is what triggered the advent of agile, 2 decades ago, right? People almost never know what they want, so put SOMETHING in front of them, fast, and let's go from there
    - nomel 9mo ago
      I've seen it many many times, a few from myself. It's not so hard if you're an expert in the field or concept they're asking the solution for, especially if you've already implemented it in the past, in some way, so know all the hidden requirements that they aren't even aware of. If you're in a senior position, in a small group, it's very possible you're the only one that can even reason about the solution, beyond some high level desires. I've worked in several teams with non-technical people/managers, where a good portion of the requirements must be ignored, with the biggest soft skill requirement being pretending they're ideas are reasonable. It's also true if it's more technical than product based. I work in manufacturing R&D where a task might be "we need this robot, with this camera, to align to align to and touch this thing with this other thing within some um of error." Software touches every industry of man. Your results may vary.
sbrother 9mo ago
I've heard this, and I've even seen it in plenty of poorly performing businesses, but I've never actually seen it in a highly performing, profitable tech company. Other than at the new grad level but it's treated as net-negative training while they learn how to build consensus and scope out work. Not coincidentally, the places I've seen this approach to work are the same places that have hired me as a consultant to bring an effective team to build something high priority or fix a dumpster fire.
- tikhonj 9mo ago
  A lot of highly performing teams don't even use tickets.
  - win311fwg 9mo ago
    Do any highly performing teams use tickets? A fly-by-night charlatan successfully pushed ticking into our organization in the past year and I would say it was a disaster. I only have the experience of one, but from that experience I am now not sure you can even build good software that way. I originally hoped it was growing pains, but I see more and more fundamental flaws.
    - yurishimo 9mo ago
      I’ve worked at one, but it required a PM who was ruthless about cutting scope and we focused on user stories after establishing a strong feedback pipeline, both technically through CI/CD/tests and with stakeholders. Looking back, that was the best team I’ve ever worked in. We split up to separate corners of the company once the project was delivered (12 month buildout of an alpha that was internally tested and then fleshed out). Maybe I had greenfield glasses but I came in for the last 3 months and it was still humming.
    - layer8 9mo ago
      How do you keep track of tasks that need to be done, of reported bugs and feature requests?
pjmlp 9mo ago
Looks very robotic to me, never worked on a place where meetings and dealing with other humans wasn't part of the job.
- Retric 9mo ago
  I’ve been on plenty of teams where meetings didn’t actually require any meaningful participation from most people.
  - pjmlp 9mo ago
    Never been the case for me, additionally I have always worked in shared desks or offices.
  - nuancebydefault 9mo ago
    Meetings without any meaningful participation from most people? I guess too many people in the meetings?
    - win311fwg 9mo ago
      That is likely referring to what has become known as the standup, where developers read off the commit log for the "manager" who hasn't yet figured out how to use a computer.
      - whstl 9mo ago
        Or for the product manager too lazy to check Jira.
falloutx 9mo ago
People gotta remember its a job just like anything else. I dont see any other profession going above and beyond so why should that be levied upon on programmers, I don't see PMs trying to understand code, CEOs trying to understand the customer more than the investor.

verelo 9mo ago

You’re right but i have always preferred people who can do a little more. Nothing against the socially awkward and conflict avoidant nature in many of these friends, but people who push back and fight to communicate their views and passions often got our team better outcomes than someone who just turns up and does the work they’re asked to do.

PunchyHamster 9mo ago
As long as it is not opposite set of skills (talks a lot without knowledge to back it up so essentially using charisma to convince people to do the wrong thing most of the time) then yes, a lil bit of negotiation can save you a whole lot of work in the long run (XY problems being one example)
- verelo 9mo ago
  For sure, I’ve been tricked into hiring those people before too. It’s good that there’s still something hard in running an organization, the whole “what is value?” question feels like it’ll be one of the few things we have to maintain work for humans over the next little while.

miav 9mo ago

Is this genuinely common? I’ve only ever seen that level of hand holding extended to new grad hires.

kube-system 9mo ago
It definitely happens at bloated organizations that aren’t really good at software development. I think it is especially more common in organizations where software is a cost center and business rules involve a specialized discipline that software developers wouldn’t typically have expertise in.
veyh 9mo ago
I have 13 years of professional experience, and I work in a small company (15 people). Apart from one or two weekly meetings, I mostly just work on stuff independently. I'm the solo developer for a number of projects ranging from embedded microcontrollers to distributed backend systems. There's very little handholding; it's more like requirements come in, and results come out. I have been part of some social circles before but they were always centered around a common activity like a game, and once that activity went away, so did those connections. As I started working on side hustles, it occurred to me that not having any kind of social network (not even social media accounts) may have added an additional level of difficulty. I am still working on the side hustles, though.
- nuancebydefault 9mo ago
  > it's more like requirements come in, and results come out. Wow someone is very good at setting requirements. I have never seen that in 25 years of dev life.
  - veyh 9mo ago
    Of course, sometimes people realize that what they asked for wasn't actually what was needed.
    - pmg101 9mo ago
      I mean... This "realization" is what triggered the advent of agile, 2 decades ago, right? People almost never know what they want, so put SOMETHING in front of them, fast, and let's go from there
  - nomel 9mo ago
    I've seen it many many times, a few from myself. It's not so hard if you're an expert in the field or concept they're asking the solution for, especially if you've already implemented it in the past, in some way, so know all the hidden requirements that they aren't even aware of. If you're in a senior position, in a small group, it's very possible you're the only one that can even reason about the solution, beyond some high level desires. I've worked in several teams with non-technical people/managers, where a good portion of the requirements must be ignored, with the biggest soft skill requirement being pretending they're ideas are reasonable. It's also true if it's more technical than product based. I work in manufacturing R&D where a task might be "we need this robot, with this camera, to align to align to and touch this thing with this other thing within some um of error." Software touches every industry of man. Your results may vary.

sbrother 9mo ago

I've heard this, and I've even seen it in plenty of poorly performing businesses, but I've never actually seen it in a highly performing, profitable tech company. Other than at the new grad level but it's treated as net-negative training while they learn how to build consensus and scope out work. Not coincidentally, the places I've seen this approach to work are the same places that have hired me as a consultant to bring an effective team to build something high priority or fix a dumpster fire.

tikhonj 9mo ago
A lot of highly performing teams don't even use tickets.
- win311fwg 9mo ago
  Do any highly performing teams use tickets? A fly-by-night charlatan successfully pushed ticking into our organization in the past year and I would say it was a disaster. I only have the experience of one, but from that experience I am now not sure you can even build good software that way. I originally hoped it was growing pains, but I see more and more fundamental flaws.
  - yurishimo 9mo ago
    I’ve worked at one, but it required a PM who was ruthless about cutting scope and we focused on user stories after establishing a strong feedback pipeline, both technically through CI/CD/tests and with stakeholders. Looking back, that was the best team I’ve ever worked in. We split up to separate corners of the company once the project was delivered (12 month buildout of an alpha that was internally tested and then fleshed out). Maybe I had greenfield glasses but I came in for the last 3 months and it was still humming.
  - layer8 9mo ago
    How do you keep track of tasks that need to be done, of reported bugs and feature requests?

pjmlp 9mo ago

Looks very robotic to me, never worked on a place where meetings and dealing with other humans wasn't part of the job.

Retric 9mo ago
I’ve been on plenty of teams where meetings didn’t actually require any meaningful participation from most people.
- pjmlp 9mo ago
  Never been the case for me, additionally I have always worked in shared desks or offices.
- nuancebydefault 9mo ago
  Meetings without any meaningful participation from most people? I guess too many people in the meetings?
  - win311fwg 9mo ago
    That is likely referring to what has become known as the standup, where developers read off the commit log for the "manager" who hasn't yet figured out how to use a computer.
    - whstl 9mo ago
      Or for the product manager too lazy to check Jira.

falloutx 9mo ago

People gotta remember its a job just like anything else. I dont see any other profession going above and beyond so why should that be levied upon on programmers, I don't see PMs trying to understand code, CEOs trying to understand the customer more than the investor.