Live data from Hacker News

The worst programmer I know

dannorth.net

551–560 of 668 posts

Re: The worst programmer I know

#551
When I got promoted to a Senior Dev, my job became totally different. All I did the whole day was talking to other teams, pair program, organize big project nobody wanted to do, take part in plannings, but hardly any coding. These responsibilities were actually included in the job description.

Re: The worst programmer I know

#553
post #25

Reminds me of an anecdote about Bell Labs. Someone calculated who the most productive employees were (based on things like patents received), and found that many of them would eat lunch with the same person. That person wasn't individually very productive, but he would always ask thoughtful, compelling questions that in turn made his coworkers measurably more productive.

It might be from the great book The Idea Factory by Jon Gertner (p 135). 'In the midst of Shannon’s career, some lawyers in the patent department at Bell Labs decided to study whether there was an organizing principle that could explain why certain individuals at the Labs were more productive than others. They discerned only one common thread: Workers with the most patents often shared lunch or breakfast with a Bell…

Rumour has it Nyquist was promised to be on 18 breakfasts a day to placate investors after a slow quarter.

Re: The worst programmer I know

#554

Earlier quoted context omitted.

I don't think code reviews are the _best_ way to teach. Because for a start, you're usually working with a complete task. Someone can have a perfectly fine pull request that implements the feature or solves the bug, but it might not be the best way of going about it. Now, as a reviewer your spidey sense tingles and you get the feeling there's a better way. But now it's significantly more effort to pull that change ap…

> But now it's significantly more effort to pull that change apart or start from scratch and experiment with a new approach, then write this all up on the pull request with the caveat "but what you've written works, so in the interest of time we can merge this" this is your issue. you’re approving prs due to perceived time constraints that you wish you could say no to. are these time constraints real? even for signif…

I think you're viewing this in a very idealistic way and not a way many companies actually operate.

You can me ask "why don't you do X". And the answer is that the culture does not support it. I have work to do, work I've been given because as senior members of the team we are pushed into bigger and more important projects. The less experienced members of the team just have more time to do things.

For me to spend 7 hours a day sitting in a call with someone would mean 7 hours of not delivering work that my manager and project managers expect to be delivered. No person in the business is going to want to spend 7 hours on a call because the culture does not encourage it. This is why I said it is uncomfortable for both parties. Taking hours of someone's time isn't seen as a good thing, it's seen negatively. Of course the person you're helping appreciates it. But the culture makes them feel guilty for asking.

Should that be the case? No. Is that the case? Yes. Am I working toward that not being the case? Yes.

I don't know why you think I'm not trying to change the culture. I've literally listed all the issues and ways to fix it. It's not an overnight switch.

Re: The worst programmer I know

#555

Earlier quoted context omitted.

Much can be done with self advocacy I was hired at a company to help scale their development because their app was growing fast but they needed a leap forward in architecture and approach or they couldn’t keep up with growth. I documented everything I did from day 1, from what I was doing as well as why. When it came review time, everything ended up reflecting really well, for I may have closed less tickets than my p…

yep, you have to be loud about your work, especially if it is not trackable via other direct metrics like ticket count

So the performance metrics are ticket count and how loud you shout about your work?

Re: The worst programmer I know

#556

Evaluating someone’s performance, especially, software engineers by non-tech people might produce dramatic results. Let me tell you a story about a friend of mine, codenamed tommy . Tommy was an IT guy with incredible skills in networking. He moved to an energy company, fully-owned and operated by the government. Just a few weeks from his arrival, they had to rebuild the entire network from scratch with new, modern,…

He should’ve had a friend make a company and bid for the job. Then, later on, Tommy could be brought on as a contractor for extra pay

Re: The worst programmer I know

#557

Earlier quoted context omitted.

1. Do the thing they pay you to do, keep your head down and watch the company light money on fire. Bonus points if after the project is inevitably late, you step in to "help" and save the day. 2. Start a consultancy company and overcharge clients to do this work. 3. Realize that many companies will not reward you for your efforts as you expect and go back to 1

While you are consultant, #3 is different. You start charging more for more bullshit mini projects which could be part of the main project. Especially for IT, it is just a whatever-you-can-stick game. I know companies doing stuff like creating 10 page proposals just for replacing a switch. Managers feel smarter when they get charged a lot for some reason.

The manager is also playing the game. Every manager has a manager, too. The n-level manager just deals with n-1 type of metrics and information.

If you're just looking at numbers, something that costs $$$ is "harder to do" than something that costs $$. Any consultant that costs $$$ provides better work (Why would I have paid $$$ if the work wasn't better? Why would anyone charge $ to give the some quality?)

Re: The worst programmer I know

#558

Reminds me of an anecdote about Bell Labs. Someone calculated who the most productive employees were (based on things like patents received), and found that many of them would eat lunch with the same person. That person wasn't individually very productive, but he would always ask thoughtful, compelling questions that in turn made his coworkers measurably more productive.

This type of person needs to start a company, they never get paid a fair wage otherwise

True for most of the working class, whose surplus labor value is siphoned away by capital.

Re: The worst programmer I know

#559

If you don’t own your company, you are always measured on optics. If the person who employs you does not optically see your value, you don’t stand a chance working there. If employment is the measurement, optics will always be important. For those who disagree, I would argue they are arguing on what would be ideal. Sure, it would be ideal to have a fully meritocratic performance system but if someone else is in charg…

Even when you do own the company, you are still measured on optics by your customers.

Really good point. Shouldn’t have included that conditional statement.

Re: The worst programmer I know

#560
post #473

Earlier quoted context omitted.

> Some firms simply hire nothing but Seniors The firms that claim to do that almost invariably do not hire people with 20 years of experience, they hire people with 2 years of experience 10 times over. Sometimes that's fine. Usually it's not.

Agreed, I will almost always take someone with 5 years of experience at a couple of good shops rather than 20 years of experience broken up across 10 different ones.

Really? I have a lot of 2 year stints, as well as some clients I worked with for 5+ years that always invariably turned into occasional month here and there.

Often the long-term guys I met are the shit guys who are coasting, still writing code as if it were 2005.

Worse still is when their language knowledge has coalesced around an old language version and they're not using any of the new stuff, as I've seen code bases that are entirely incompatible with new libraries.

Like all new libraries generally depend on DI, but all the code is written in static methods and classes so nothing can be easily injected and you get all sorts of threading issues when you try.

Post reply on HN