Comment by greedo | Hacker News Reader

Comment by greedo | Hacker News Reader

Parent Full thread

Just to address "d" in your list. Consensus is hugely important in team environments. If you're an indie dev, do what makes you happy (and profitable). But if you're in a team, be a team member.

My team just had an coworker leave for another team. This coworker was very smart, very hardworking, and very dedicated. But he continually chafed against any sort of documentation or communication. He also chafed against any established standards or policies; pretty much did what he wanted, and was never really called on the mat for these issues.

He got away with this because he was a "rockstar." He could solve some pretty hairy problems fairly quickly. But explaining these fixes to others was difficult for him, and many of his solutions were MacGyver-esqe. He had come from a small shop where he wore many hats; we're a large enterprise with lots of teams. This means that communication is probably the most vital skill for team success.

Since he didn't share or document his changes and fixes, the remaining team members are now left trying to divine what he did. While I blame him for a lot of this behavior, I primarily blame his manager who continually tolerated it. Ironically, this manager is shocked and confused as to why he lost his rockstar.

Skill and talent are at odds with process heaviness. Oftentimes I think it's a "pick one" type of scenario. Do you want critical thinkers who just "get it" when it comes to complex technical matters? Or do you want process rigor?

Someone will say "false dichotomy", to which I say, "maybe".

Process heaviness is not a goal. The secret is to be as close to the minimally viable as is safe.

Undocumented code and decisions are just a more slowly accumulating cost, it is no less costly than bad or failing code.

This is a reason I love having outspoken and extroverted devs. The guys who love to talk so much that they will explain in extreme detail and at length.

I was reading through an old bug yesterday, and the guy who had done some work in that area had left a 5 paragraph explanation of what had gone wrong, what he thought may have caused it and some things he was planning on doing. Having that written down was invaluable when I got to the thing a year later.

Process rigour is not the goal. Communicating what is strange and different is. If you have guys who do that naturally, great. If not, you need some process.

> This is a reason I love having outspoken and extroverted devs. The guys who love to talk so much that they will explain in extreme detail and at length.

In my experience, the devs that talk the most, know the least about how things actually work. They churn off trying to explain something and are either subtly or blatantly wrong, and you've got to reel them in before they get down the rabbit hole and misrepresent reality too badly. It can be catastrophic if they are interfacing with management or customers.

It seems to be a manifestation of the classic "baffle them with bullshit" strategy for dealing with ignorance or incompetence.

If you follow a consistent process, that can often make you look like you are a "rockstar". I find many people are so random, and don't approach their work in any kind of structured or analytical way, that doing things takes them much longer than it ought to. At the end of the day, rolling up your sleeves and actually doing some work goes a startlingly long ways. And most of all, test your fricking code yourself, at least run it, anything - I've lost track of the number of times that people just check shit in that would be blindingly obviously broken if they had even tried using the feature that they supposedly worked on.

I wouldn't say that it's either/or with respect to the person, so much as two types of activities/skills that interfere with each other.

Coming up with innovative solutions to complex technical problems requires you to be in the weeds, and think non-linearly (e.g. using intuition); while communication requires abstraction to (preferably) only the most important elements, and linear composition of the ideas into speech or text.

Why did the manager lose the rockstar? It reads like the rockstar was pretty happy in his role, doing what he wanted.

Reply on news.ycombinator.com