6 ms·

I'm the author of the post - would love any feedback / similar experiences / contrasting opinions!

by zachlloyd 5y ago

theandrewbailey 5y ago
I'm not sure what IC means. Integration Consultant? Industrial Control?
- mLuby 5y ago
  Individual contributor, in other words a worker as opposed to management. The author's using engineer to mean software developer; they're the workers in this context.
- conro1108 5y ago
  Individual contributor (as opposed to management)
  - zachlloyd 5y ago
    Correct! IC == individual contributor. Sorry for any confusion
- juice_bus 5y ago
  I believe IC is "Individual Contributor" in this context.
  - ilrwbwrkhv 5y ago
    A most bizarre terminology the industry has come up with. Almost feels a bit derogatory.
    - zaat 5y ago
      That's the natural way languages develop, offensive terms replaces with euphemisms, given some time every euphemistic term become loaded with the same negative connotations of its origin and new euphemism get introduced. see: https://thelingspace.tumblr.com/post/114432905996/the-euphemism-treadmill https://thelingspace.tumblr.com/post/114432905996/the-euphem...
    - Sohcahtoa82 5y ago
      Better than grunt, peon, peasant, minion, or drone.
- disposableuname 5y ago
  > as both an IC and a manager When juxtaposed to manager, it usually means individual contributor - someone being managed rather than doing the management.
- alboy 5y ago
  Itty-bitty Cog.
grumple 5y ago
I'm getting a 500 error when I visit the site.
eatbitseveryday 5y ago
Please write the insight into the title of the post, rather than hiding it under a click-bait. Your site is down now due to traffic and the original HN title (reflecting the title of your writing) provides no value.
- zachlloyd 5y ago
  yup, i messed this up, apologies. site is handling the traffic better now thanks to cloudflare
908B64B197 5y ago
In this industry we use "developer" and "engineer" interchangeably, but one is not like the other. They don’t hand out brass rats at the end of a bootcamp… > For early career engineers, it often happens because they lack practice working on teams. They train in school environments where they do classroom projects on their own, or work on long-term intern projects in a silo. Serious engineering school would have student work together to ship projects.
- afarrell 5y ago
  Yes, MIT’s university culture does genuinely encourage a collaborative project-based approach. However, some grads will believe that the business world expects them to be as brilliant as Tony Stark and able to “carry a message to garcia”[1]. If a course-VI grad wearing brass rat thinks a request for help/feedback will be rebuffed as impostor syndrome (it happens), they can make the same mistake. Ego is the enemy. The blog post’s advice still applies. [1] https://courses.csail.mit.edu/6.803/pdf/hubbard1899.pdf https://courses.csail.mit.edu/6.803/pdf/hubbard1899.pdf which is both historically apocryphal and only good advice when dealing with an impatient and incurious leader.
waynecochran 5y ago
I am an older software engineer and have noted that a lot of introverted engineers love to work in their own silos. Some of the smartest engineers are introverted and do not want to be bothered; worse yet, because of pride they often do not "suffer fools" well and avoid working with others. Working with a group of smart and humble engineers that are constantly "borrowing each other's" brain is very effective and enjoyable experience. And everyone has a good sense of what everyone else is working on -- sunk cost is more frequently avoided.
- nuancebydefault 5y ago
  I feel the same way. Lot's of experienced engineers don't like to be bothered too much, have the feeling they know best and just design and implement the way they have it in mind. Juniors on the other hand don't like to bring their beginners mistakes too much in the open, hence they work hard and long to avoid that. Both of these situation are largely sub-optimal. A good manager knows this and asks for feedback in time, in an interested way, without being too pushy.
jseban 5y ago
The description of the "problem" is that the requirements specified in the beginning were wrong, and then the developer is blamed for solving exactly what was specified, and not constantly asking management every day "have you changed your mind?". I don't understand at all, how this is the fault of the developer, talk about expecting the developer to bend over backwards for any product manager. How is it not reasonable for management/PO to be responsible for 1. sending devs off in the wrong direction, and 2. not notifying them as requirements change? This is just another way of saying "management is right, even when they're wrong, and you need to accept that".
- Jabbles 5y ago
  Non-trivial problems often require exploration of the solution space. You're not expected to ask management if they've changed their mind, you're meant to present your finding so far, and ask if they have any feedback. Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for. Computers can get away with it.
  - jseban 5y ago
    > Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for. Getting paid for doing what someone tells you to do, is literally the definition of a job. What you're saying actually, is that it's not your job to do your job, it's your job to also do the managers/PO's job.
    - Jensson 5y ago
      You also get paid to be the scapegoat for when your manager fails to do his job, like in this story.
friendlydog 5y ago
I'm a fan of "always loop people in". Frequent checkins with detailed commit messages including markdown and graphviz diagrams which state intentions. Switching the flow from a status meeting low detail reponse of "still working on X issue" to a regular feed of detailed information which serves not only as a development log, documentation, but it crystallizes the developer's planning and thought process because they have to describe what they are doing rather than just "fixing the issue" , or "building the thing". Persistent chat has made daily stand up status calls redundant. Stakeholders can subscribe to channels which have rich detailed information about what is happening at any given moment. For larger groups a resource can curate the channels and provide a thoughtful summary in a higher level channel of different teams progress. Tools like Azure Dev Ops provide meaningful charts, tracking, and velocity, and the deeper conversations on chat linked to work items, wikis, and repo level filea serve to provide an accurate picture for anyone looking into the effort. Leads, and managers can identify trouble spots and adjust priorities or provide valuable insights. Regular demos can also be linked and serve as a historical record of the development direction.
jkaptur 5y ago
It's great to see "I'm still exploring X" called out as a standup antipattern. I've heard and (hi Zach!) said this many times. ... But I've generally heard it most frequently from the tech lead and/or manager at the standup. It's easy to justify: "as the TL/M, my work is ill-defined, meeting-heavy, complex, externally-focused, and long-term! I'm not just building a feature! It's hard to describe!" In my experience, this culture percolates with lightning speed: more junior folks immediately understand that to be senior and high-status is to give vague updates (often with a dramatic sigh and a self-deprecating joke about getting nothing done). So it's good to exhort feature-building ICs to show incremental progress on that feature, but I think this article should have a heavier focus on the most senior folks at the standup.
chrismorgan 5y ago
I can’t load the page due to a redirect loop: it does a 301 redirect to the same URL. Observed from Australia, in Firefox, curl and Chromium, all under Linux, talking to 66.235.200.155.

I'm the author of the post - would love any feedback / similar experiences / contrasting opinions!

theandrewbailey 5y ago

I'm not sure what IC means. Integration Consultant? Industrial Control?

mLuby 5y ago
Individual contributor, in other words a worker as opposed to management. The author's using engineer to mean software developer; they're the workers in this context.
conro1108 5y ago
Individual contributor (as opposed to management)
- zachlloyd 5y ago
  Correct! IC == individual contributor. Sorry for any confusion
juice_bus 5y ago
I believe IC is "Individual Contributor" in this context.
- ilrwbwrkhv 5y ago
  A most bizarre terminology the industry has come up with. Almost feels a bit derogatory.
  - zaat 5y ago
    That's the natural way languages develop, offensive terms replaces with euphemisms, given some time every euphemistic term become loaded with the same negative connotations of its origin and new euphemism get introduced. see: https://thelingspace.tumblr.com/post/114432905996/the-euphemism-treadmill https://thelingspace.tumblr.com/post/114432905996/the-euphem...
  - Sohcahtoa82 5y ago
    Better than grunt, peon, peasant, minion, or drone.
disposableuname 5y ago
> as both an IC and a manager When juxtaposed to manager, it usually means individual contributor - someone being managed rather than doing the management.
alboy 5y ago
Itty-bitty Cog.

grumple 5y ago

I'm getting a 500 error when I visit the site.

eatbitseveryday 5y ago

Please write the insight into the title of the post, rather than hiding it under a click-bait. Your site is down now due to traffic and the original HN title (reflecting the title of your writing) provides no value.

zachlloyd 5y ago
yup, i messed this up, apologies. site is handling the traffic better now thanks to cloudflare

908B64B197 5y ago

In this industry we use "developer" and "engineer" interchangeably, but one is not like the other. They don’t hand out brass rats at the end of a bootcamp… > For early career engineers, it often happens because they lack practice working on teams. They train in school environments where they do classroom projects on their own, or work on long-term intern projects in a silo. Serious engineering school would have student work together to ship projects.

afarrell 5y ago
Yes, MIT’s university culture does genuinely encourage a collaborative project-based approach. However, some grads will believe that the business world expects them to be as brilliant as Tony Stark and able to “carry a message to garcia”[1]. If a course-VI grad wearing brass rat thinks a request for help/feedback will be rebuffed as impostor syndrome (it happens), they can make the same mistake. Ego is the enemy. The blog post’s advice still applies. [1] https://courses.csail.mit.edu/6.803/pdf/hubbard1899.pdf https://courses.csail.mit.edu/6.803/pdf/hubbard1899.pdf which is both historically apocryphal and only good advice when dealing with an impatient and incurious leader.

waynecochran 5y ago

I am an older software engineer and have noted that a lot of introverted engineers love to work in their own silos. Some of the smartest engineers are introverted and do not want to be bothered; worse yet, because of pride they often do not "suffer fools" well and avoid working with others. Working with a group of smart and humble engineers that are constantly "borrowing each other's" brain is very effective and enjoyable experience. And everyone has a good sense of what everyone else is working on -- sunk cost is more frequently avoided.

nuancebydefault 5y ago
I feel the same way. Lot's of experienced engineers don't like to be bothered too much, have the feeling they know best and just design and implement the way they have it in mind. Juniors on the other hand don't like to bring their beginners mistakes too much in the open, hence they work hard and long to avoid that. Both of these situation are largely sub-optimal. A good manager knows this and asks for feedback in time, in an interested way, without being too pushy.

jseban 5y ago

The description of the "problem" is that the requirements specified in the beginning were wrong, and then the developer is blamed for solving exactly what was specified, and not constantly asking management every day "have you changed your mind?". I don't understand at all, how this is the fault of the developer, talk about expecting the developer to bend over backwards for any product manager. How is it not reasonable for management/PO to be responsible for 1. sending devs off in the wrong direction, and 2. not notifying them as requirements change? This is just another way of saying "management is right, even when they're wrong, and you need to accept that".

Jabbles 5y ago
Non-trivial problems often require exploration of the solution space. You're not expected to ask management if they've changed their mind, you're meant to present your finding so far, and ask if they have any feedback. Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for. Computers can get away with it.
- jseban 5y ago
  > Simply stating that you did as instructed is not a viable excuse for a human, that's not what they're paying you for. Getting paid for doing what someone tells you to do, is literally the definition of a job. What you're saying actually, is that it's not your job to do your job, it's your job to also do the managers/PO's job.
  - Jensson 5y ago
    You also get paid to be the scapegoat for when your manager fails to do his job, like in this story.

friendlydog 5y ago

I'm a fan of "always loop people in". Frequent checkins with detailed commit messages including markdown and graphviz diagrams which state intentions. Switching the flow from a status meeting low detail reponse of "still working on X issue" to a regular feed of detailed information which serves not only as a development log, documentation, but it crystallizes the developer's planning and thought process because they have to describe what they are doing rather than just "fixing the issue" , or "building the thing". Persistent chat has made daily stand up status calls redundant. Stakeholders can subscribe to channels which have rich detailed information about what is happening at any given moment. For larger groups a resource can curate the channels and provide a thoughtful summary in a higher level channel of different teams progress. Tools like Azure Dev Ops provide meaningful charts, tracking, and velocity, and the deeper conversations on chat linked to work items, wikis, and repo level filea serve to provide an accurate picture for anyone looking into the effort. Leads, and managers can identify trouble spots and adjust priorities or provide valuable insights. Regular demos can also be linked and serve as a historical record of the development direction.

jkaptur 5y ago

It's great to see "I'm still exploring X" called out as a standup antipattern. I've heard and (hi Zach!) said this many times. ... But I've generally heard it most frequently from the tech lead and/or manager at the standup. It's easy to justify: "as the TL/M, my work is ill-defined, meeting-heavy, complex, externally-focused, and long-term! I'm not just building a feature! It's hard to describe!" In my experience, this culture percolates with lightning speed: more junior folks immediately understand that to be senior and high-status is to give vague updates (often with a dramatic sigh and a self-deprecating joke about getting nothing done). So it's good to exhort feature-building ICs to show incremental progress on that feature, but I think this article should have a heavier focus on the most senior folks at the standup.

chrismorgan 5y ago

I can’t load the page due to a redirect loop: it does a 301 redirect to the same URL. Observed from Australia, in Firefox, curl and Chromium, all under Linux, talking to 66.235.200.155.