Earlier quoted context omitted.
I believe IC is "Individual Contributor" in this context.
A most bizarre terminology the industry has come up with. Almost feels a bit derogatory.
Better than grunt, peon, peasant, minion, or drone.
Doing too much work on one's own before looping in others
231–240 of 395 posts
Re: Doing too much work on one's own before looping in others
#232Earlier quoted context omitted.
I wholeheartedly agree, if you need daily feedback you're a bad manager (unless you're in some exotic situation like a rocket launch or something). This issue largely disappears if your engineers are given the proper context, background and system overview. I'm not advocating everybody should take their project and run with it for weeks on end, but daily updates are ridiculous.
I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…
I think most people are salty about your comment because they fail to see the subtle difference between:
1) "Everyday you should ship something" 2) "At the end of each day you should be able to tell your line manager in a clear and concise way exactly what you did; if you can't you've done nothing."
2) does not mean ship code: you could have spent 12 hours thinking and reading code. But if you can explain i.e provide a daily update, then you have actually done something, and not spent a day on slack sending memes.
i've had days where I did nothing but read code trying to understand a bug, and then my whole contribution was 1 line of config or 2 lines of code. But I have a clear achievement: I understood an area of the code much better and i have a fix.
Having daily updates to your manager also forces you to not slack and work on the most important problems: otherwise you might be tempted to work on sth fun but not mission critical.
At the end of the day, people should do as they wish.
Re: Doing too much work on one's own before looping in others
#233Earlier quoted context omitted.
> It also offers chance to produce memorable work as nobody remembers the set of 3 point tasks you completed ten sprints ago. This is one of the more toxic ones. To get past senior, you often need to be seen to do Big Memorable Things. It sometimes leads to perverse incentives.
I mean it's not that toxic, if you are a good worker bee your manager will usually notice and be happy with your performance. Then from time-to-time you branch off to do something more high-risk to add to your promo doc. I think a lot of people have weaker communication skills than execution skills. So they could loop in everyone early on, but their idea might get killed off because they failed to justify it properly…
> If instead they leverage their execution skills and make an MVP that will speak for itself, then they bypass that issue.
Hell yes. Forgiveness beats permission every single time.
Re: Doing too much work on one's own before looping in others
#234I'm good at working on a team and looping in others. I also find it to be one of the most exhausting parts of software development. It's so difficult to constantly need to get feedback and buy-in from other people, and takes away a lot of the creativity and joy in programming (for me). Which isn't to say you shouldn't do it, just that it's one of the things that makes me dislike working on a team. I actually think th…
> Writing code as a team is almost like writing a novel with a few dozen other people, all of which have differing ideas on how the book should be written, or even what it should be about. It's hard to feel the joy in creating something when you're only a small cog in the development machine, and every decision needs a dozen voices of input.
I believe this is why books most often have a single author. A solution to this, is to agree on the global design, and then have different developers own different "modules" of the design. These modules should be treated like third-party libraries (and should act like third-party libraries vis-a-vis of their documentation and API).
Basically, microservices can exist within your code if you know how to modularize well.
Re: Doing too much work on one's own before looping in others
#235I was more often than not 'guilty' of what the author describes. And I actually love being the lone detective on the hunt for a cool solution. I am not a dev by trade (data analyst) but still love to work on problems solved in code. A lot of the advice hit home, but what struck me was this part: > Encourage engineers to get something end to end launched internally as quickly as possible. This is something my boss nev…
and then it never gets refactored.
But essentially I agree with you, good writers use the same technique: write once, revise many times.
Good code, IMO, only exist after many refactors.
Re: Doing too much work on one's own before looping in others
#236Earlier quoted context omitted.
> It also offers chance to produce memorable work as nobody remembers the set of 3 point tasks you completed ten sprints ago. This is one of the more toxic ones. To get past senior, you often need to be seen to do Big Memorable Things. It sometimes leads to perverse incentives.
To me moving beyond senior means you enable the entire team to contribute together accomplish Big Memorable Things. This can mean a ton of things, which cannot all be served by a single senior+ engineer: * mentorship * seeking out, establishing, and evangelizing best practices, and not just coding best practices: architecture, documentation, testing, ci/cd etc * high-level architecture knowledge and experience * eval…
If every senior only does internal assistant work, which senior does actual building of complex services?
What is more important? Building better services or being a library writer?
Every point you describe is exactly perverse incentives.
Re: Doing too much work on one's own before looping in others
#237Earlier quoted context omitted.
If this approach results in you taking limited and short term views of development, or low quality software with unhappy developers, you're doing it wrong. Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).
Not all development fits nicely into day-or-two chunks. Forcing all your work to fit nicely into this type of mold is an arbitrary restriction that serves no real purpose except to check all the necessary scrum boxes, give the illusion of extra productivity, and allow for micro-management. It ends up being completely antithetical to thinking deeply and long term about the the code you're writing. I've worked on teams…
What do you think of the idea that providing finished work on an every-day-or-two cadence allows you to collect feedback from your customers in a way that keeps your work focused and relevant to their needs?
Re: Doing too much work on one's own before looping in others
#238Earlier quoted context omitted.
I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time). In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to…
I think most people are salty about your comment because they fail to see the subtle difference between: 1) "Everyday you should ship something" 2) "At the end of each day you should be able to tell your line manager in a clear and concise way exactly what you did; if you can't you've done nothing." 2) does not mean ship code: you could have spent 12 hours thinking and reading code. But if you can explain i.e provide…
Yeah, I think it's telling that folks here assumed I meant "give daily feedback" as in "tell your boss what you're up to".
It's probably a lot more effective to keep your team up to date on what you're doing, than it is to keep your boss up to date on what you're doing, and that's where I was focusing.
And yeah, while I did say "ship functionality", you're right, the real value is producing something you can show users. I prefer that ends up being code, because otherwise users are hard to pin down, but it doesn't have to be.
Finally yes, people should do as they wish, but with the understanding that if the thing they'd prefer to work on isn't the thing the team they're working on needs, that the team should be able to go find someone who does want to do the thing the team needs. It's not really fair to drag a team down because one person isn't having fun.
Re: Doing too much work on one's own before looping in others
#239> "the biggest mistake I see engineers make is doing too much work on their own before looping in others" > "For more senior engineers, it can happen because they like to work on their own and may be overconfident in finding solutions. It can also happen if the team culture is toxic and engineers fear getting criticism early in the design process." Not saying the above statement is incorrect but here is an alternativ…
You are not wrong. I generally sell as a mercenary, and prefer it that way - I've been doing this longer than some of my managers have been alive. I'm paid just as well if they want to "pair program" or jira the whole process, but yeah, you hired me to fix a problem - if you are the problem, I get paid just the same. Welcome to the real world, if your work is interesting, the clock might not turn on when I'm having f…
I like the cut of your jib
Re: Doing too much work on one's own before looping in others
#240I was more often than not 'guilty' of what the author describes. And I actually love being the lone detective on the hunt for a cool solution. I am not a dev by trade (data analyst) but still love to work on problems solved in code. A lot of the advice hit home, but what struck me was this part: > Encourage engineers to get something end to end launched internally as quickly as possible. This is something my boss nev…
It might be good advice, but that's not engineering in concept, spirit, or practice of the term. I don't usually pick an absolute, decisive side in the "what counts as engineering" debate, but this is the opposite of engineering.
Lol, you think physical engineers don't throw together prototypes that they know won't be good enough for the final design just to get everything working together?