Earlier quoted context omitted.
Pairing is only helpful when you are new and learning from someone more experienced. However, it may be a time-sink for the more experienced person, who could be using their limited time on more critical things. That's why newbies get assigned a mentor, with whom they can pair freely. But pairing rigidly with the whole team just sucks and is incredibly unproductive.
I've had similar experiences. I vocalize a lot (in my head) during the development process, and I've noticed that when I have to engage with another person during this time I start vocalizing audibly, which is where the problems start. The other person gets confused because I'm speaking the snippets and half-ideas that are passing through my mind at the moment (and the internal jargon I've developed over the decades)…
Doing too much work on one's own before looping in others
301–310 of 395 posts
Re: Doing too much work on one's own before looping in others
#302Earlier quoted context omitted.
I think criminal defense is a great service to humanity. It's hard to estimate how many are wrongfully accused, but surely there are many. Further, things like the plea bargain system or parole regularly lead innocent people to proclaim their guilt. It's very messed up and must be a terrible trauma for some. Lastly, I think even guilty people deserve humane treatment and perhaps forgiveness.
> and perhaps forgiveness. I would agree here, on the condition of rehabilitation. Obviously our "justice system", isn't. Edit: Speaking of the US above, no experience or knowledge about other countries systems. It appears I've found a new gap in my knowledge, anyone have a good intro to how courts work in their country?
There is no such thing as plea bargaining (which is considered a perversion of justice) or bail (which is considered to be jailing the poor). People are rarely jailed pending trial (unless their place of residence cannot be established, or they're considered a flight risk - a very high bar to pass). There's no "perp walk" or handcuffs or any of that humiliation stuff (unless you actually ARE being a pain). After the verdict, you're usually given a month or two to tie up your affairs outside before being ordered by mail to report to prison.
The relationship between lawyers is one of cooperation (albeit with the agenda of pushing towards their point of view). The purpose of the court proceedings is to get to the truth of the matter. There are no theatrics, no grand speeches, no "chewbacca" defense. Withholding evidence or deliberately hampering the other side is severely frowned upon. "Winning" the case is not the point; representing your side well is. Lawyers have no election aspirations, and thus no public to impress with their prosecutorial prowess. One cannot become a judge without years of training and a degree (there's no such thing as elected judges).
The result is a very calm, organized court proceeding, because everyone involved knows the law and is committed to it. You can't bamboozle with doublespeak, shady arguments or unproven methods because there's no "man on the street" juror to deceive; only the judges, who are trained to know better.
Anyone can sit in on a proceeding (I've done so). There's very little ceremony, and often it's just a bunch of people sitting around conference tables in a small room.
Re: Doing too much work on one's own before looping in others
#303This is a bit of a nuanced topic with lots of shades of truth or context, and overall I agree with the article, but that said: Sometimes you know your team is going to do the stupid shortcut if you let them and you save them from themselves by solving the robust solution before they have a chance to "be pragmatic" and pointlessly bikeshed about things that don't matter to waste your time. Sometimes you know it will t…
Re: Doing too much work on one's own before looping in others
#304Earlier 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 used to work at an R&D company. While that cadence is possible in a website mill, it’s a laughable blanket statement.
Re: Doing too much work on one's own before looping in others
#305Earlier quoted context omitted.
A lot. Technical managers need not be experienced technical talents who have made a potentially incompatible shift to management.
It is better if the managers of technical people are technical themselves. Otherwise you wind up with the Dilbert "pointy-haired-boss" syndrome. The non-technical manager is extremely easy to bullshit, so it's better for the company in almost all ways.
They should not be making technology decisions or specifying how the work gets done. They should trust their reports to not bullshit (and if that trust is broken, those reports should be fired). I think having a technical background can be helpful for these managers, but I don't think it's strictly necessary, and they should be doing essentially zero technical work as a part of their management job.
I've found managers who are like this to be incredibly useful and productive, and a pleasure to work with. Managers who want to get involved in technical decisions just get in the way and cause problems. Unfortunately a lot of newly-promoted former engineers can't let go of the technical work.
Re: Doing too much work on one's own before looping in others
#306Earlier quoted context omitted.
When you think you're fooling someone, you're really only fooling yourself. It doesn't take a genius to know who is doing the work and who is looking for every excuse to be 'blocked'. Managers simply know that they can't hire or fire and that calling someone on their bullshit would accomplish nothing, so they say nothing. Managers are masters of soft power. Soft power is very hard for engineering/techie types to unde…
There is a lot of bullshit in this comment.
Most developers I know are good at human interactions, some even among the best.
I don't want to be put in that box, and I'm not willing to excuse someone bad at human interactions because they are technical.
Obviously some people are better at human interactions than others, and I'll be happy to adapt, but let's not imply causes.
Re: Doing too much work on one's own before looping in others
#307> "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…
> 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.
Taking chance to do a bit of focused work and actually do it in that environment is not toxic. It is not like you have run of for months and refused to communicate. It is just ... getting slight bit of rest.
Re: Doing too much work on one's own before looping in others
#308I have two big rules for developers that report to me: 1. The 5 minute rule. If you are stuck for more than 5 minutes reach out. Once the developer is on the team for a while, this becomes 15 or 30 minutes. Caveat ... truly stuck ... tried a couple of things, googled, tried some more ... wondering what to try next. One thing I try to do with a new start is go ask them for help in the same way, "Hey, 5 minute rule, I'…
That is not even possible within 5 minutes.
I would not want to work there honestly. Just being unable to solve problems demotivates me. It sounds like I will get off everytime I am slightly slower to pick something. This would be too stressful for me.
Re: Doing too much work on one's own before looping in others
#309I'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…
> It's disempowering to feel like you're never able to make a decision yourself, despite supposedly being hired for your expertise in the field. I'm going through exactly this at the moment. For reasons HN will probably consider fiction, my superiors have started treating me as a toddler that needs oversight on every single decision that needs to be made. It's something I've been dealing with in therapy, and the way…
Re: Doing too much work on one's own before looping in others
#310This whole post strikes me as somebody making up a world as he believes it ought to be and then suggesting advice for navigating that world, rather than the real one. For example: > Always encourage engineers to show their work as quickly as possible Yep, that sounds like great advice. On "paper", anyway. I tried to do that when I first started out, too. What I found was that communicating "this is just an early draf…
Generally the higher up the food chain the less likely that people will 'get it' if it is not an extremely polished Proof-of-Concept (there are exceptions of course).
If I am going to play amateur psychology, I would say that people who are generally more perfectionist types and are likely get caught up in details are less likely to give a healthy review on work-in-progress.