Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The worst programmer I know

dannorth.net

Post reply on HN
Print view View original

371–380 of 668 posts

Re: The worst programmer I know

#371

Post by fabianholzer »

Stratoscope wrote: post #304

Some 20 years ago, I worked at a moderately large software company that sold a desktop application for Mac and Windows. The team had mostly Mac experience and they were just getting their feet wet with Windows. So naturally the Windows version had some problems. At the time, I was known as a "Windows expert", so they hired me to help improve that version and help the team get more familiar with Windows programming. I…

What happened after the mediocre performance review? Did leave for greener pastures asap? Did you start to optimize for their performance metrics, and stop being generous with your time? Or could you manage to convince somebody high enough above you in the org-chart that they actually hired you for what you thought they did?

Re: The worst programmer I know

#372

Post by teirce »

mlhpdx wrote: post #316
AStellersSeaCow wrote: post #95

Earlier quoted context omitted.

Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor. It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role i…

The TL role is a little restrictive IMHO. I’ve worked with very junior people who have a very effective ability to pair and improve others’ effectiveness. Perhaps as they learn they also teach.

This was my experience as well. It's completely up to management to recognize these kinds of engineers regardless of role name or leveling.

Re: The worst programmer I know

#373

Post by jonhohle »

raincom wrote: post #185
Philip-J-Fry wrote: post #124

I wish I could pair program more. I have so much knowledge to give other members of my team. Domain knowledge, programming knowledge, common pitfalls, etc. You get a code review pass at the time of writing the code, and it means you have more opportunity to change things for the better. Once it's written there's not much appetite for drastically changing working code during code review unless there's a really good re…

In almost all companies, even seeking help is frowned upon. One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'. Some actively don't want to help out others, due to PIP/bonus culture. At Amazon, some team members explicitly give bad advice when asked for help. That's why we have this culture of "lone rockstars", who spend a lot of time to learn without being mentored.

If someone is intentionally giving bad advice, that sounds like they deserve some anytime feedback. (is that still a thing?) That is definitely not thinking like an owner.

Re: The worst programmer I know

#374

Post by benreesman »

jongjong wrote: post #18

It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…

You’re largely correct but I think your comment might not nail the root cause (not saying you don’t know this, just that your comment doesn’t emphasize it).

When a market is competitive, the things that matter are roughly: hard work, candlepower, and optics/neurotypicality/maneuver in that order.

When a market is fairly sewn up that order becomes roughly: optics, candlepower, ethical flexibility, hard work in that order.

The hard-ass nerds who don’t give a shit about corporate culture du jour are treated like royalty when someone might fuck your business up.

While “purged” is a strong word, I take your meaning, and whatever we want to call it, it happens when competition is largely pro-forma.

Human beings will do anything to avoid selecting on merit except lose. That’s just human nature. Being mad about it is like yelling at the wind, but compared to even a decade ago, I’m not sure how high I’d be holding my head in today’s competitive landscape for high-prestige achievement.

Re: The worst programmer I know

#375

Post by teirce »

jimmaswell wrote: post #370
Philip-J-Fry wrote: post #124

I wish I could pair program more. I have so much knowledge to give other members of my team. Domain knowledge, programming knowledge, common pitfalls, etc. You get a code review pass at the time of writing the code, and it means you have more opportunity to change things for the better. Once it's written there's not much appetite for drastically changing working code during code review unless there's a really good re…

Pair programming sounds so stressful and unproductive to me. You can't read someone's mind. Any interjections while someone is in the middle of coding can't be more than distracting noise most of the time. And I would constantly feel self conscious that I'm taking too long to write something, googling or asking Copilot stupid questions, etc. Reviewing after the programmer believes it's ready to review makes much more…

The point of pair programming isn't really to be talking to someone while they are coding a known solution. It's to work through and discover a solution together to an unknown. In this sense, you're kind of both in the same headspace together, and can have a conversation without necessarily breaking focus. And I would venture that almost any question that comes up in pair programming would either come up later in code review, or could be hand-waved with "yeah, I plan to fix that with X" and move on.

The important part of pair programming isn't really the programming per se, it's the discussion.

It also requires some amount of conversational art. As for being self conscious about things, you would have poor coworkers who make you think that or some unfounded worry. A good pair programmer can have a discussion without making you feel like an idiot - much the same as a good code review.

Re: The worst programmer I know

#376

Post by twic »

tchaffee wrote: post #305
twic wrote: post #290

Earlier quoted context omitted.

This is just not something that actually happens.

Can you reassure me then with the data that backs up your claim? Because in my very long career I've seen a lot of people use heuristics when deciding who to follow up with. "According to a 2018 CareerBuilder survey, 70% of employers check out applicants’ profiles as part of their screening process, and 54% have rejected applicants because of what they found."

HR are not going to reject an incredibly experienced senior guy with a CV as long as your arm because of the title of a blog post. Your quote doesn't even suggest they would, and I'm not going to cite any evidence because it's honestly just a patently absurd proposition.

Re: The worst programmer I know

#377

Post by onion2k »

whstl wrote: post #301
AStellersSeaCow wrote: post #95

Earlier quoted context omitted.

Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor. It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role i…

Tech Lead is a very difficult role. :/ If you are immature or competitive, you cease being a force multiplier to be a morale destroyer. If you are more of a domain expert than your Product Managers, you will spend your time fighting and refining tasks to build features the right way. If you don't have enough time to code, you'll go obsolete.

I'm the frontend lead in a company of about 200 people (mostly devs) these days, and the idea of being a force multiplier is spot on. I'm not there to be the best dev or the most knowledgable; I'm there to lead the conversation and amplify people who are saying good things. Having a pretty deep understanding of the tech is useful so I can tell what those good things are. I am absolutely not in the company to show off or take credit for what my teams do.

Where I disagree is with the idea of fighting with product owners. If there's a disagreement around approach or tech choices that's a sign we don't have enough information. Fighting or refining won't solve that. It's a signal that we need to do more discovery work and understand the problem better.

Re: The worst programmer I know

#378

Post by wizerdrobe »

spyhi wrote: post #265
mattlondon wrote: post #182

Personally I want the seniors on my team actually delivering on the really hard stuff. Helping juniors do their job is great and all, but you still need experienced people to work on the hard and complex stuff that juniors can't because they don't have the knowledge/experience/people-skills. No amount of pair programming can replace that. You don't want to be in a situation where you have really really well implement…

A senior engineer can work through a hard problem assigned to a junior engineer, resulting in a well-implemented hard feature and a less junior engineer. Just because a junior engineer is working on it doesn’t mean by default it’s an easy problem—how are you going to grow your engineers otherwise?

Some firms simply hire nothing but Seniors. You trained up a Junior-Mid-Senior? Cool, well offer him 20k more and call it a day.

Re: The worst programmer I know

#379

Post by ajmurmann »

We all know Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure". Quantitive measure done't work well and especially not for something as complex as software development. They might tell you were to look more closely at best. Qualitative assessments work much better, but those require trust. As soon as going gets tough for a company or department, trust weakens, doubt increases and higher management, especially if they don't understand software dev well, will require quantitive metrics. It's bad, but we'll never get rid of the mess because of organizational dynamics.

Re: The worst programmer I know

#380

Post by gemstones »

zlg_codes wrote: post #318
jokethrowaway wrote: post #249

Earlier quoted context omitted.

[flagged]

Unions may be different in your part of the world. In America, it's one of the only ways for blue collar or other production-oriented workers to have any degree of leverage at the negotiation table. We are treated like cattle in the workplace, and though unions come with their fair share of problems (due to it being yet another leadership structure to work within), the idea of workers holding power as a group is esse…

It’s funny you mention it as a charisma roll, because it’s not really a roll, is it? High charisma is high when it’s with your interviewer, when it’s with your peers, when it’s with your business stakeholders. High charisma is useful in getting a job, in arguing for addressing tech debt, in pushing back on unreasonable timelines. Why would you not consider charisma in a job interview?
Post reply on HN