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

651–660 of 668 posts

Re: The worst programmer I know

#651

Post by theshrike79 »

rramadass wrote: post #640
psunavy03 wrote: post #636

Earlier quoted context omitted.

It's basically a trope on this site for everyone to imply that everyone who doesn't have their fingers in code 8+ hours a day has a so-called "bullshit job," as if developers don't work for businesses which have to earn money, so forgive my skepticism. And yes . . . I do code.

You have missed the point. It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it…

There is a difference between "understanding the work" and "knowing how to do the work".

I've had multiple Producers who "understand the work" of creating mobile games as a whole and understand how the team needs to work and interact to produce a result on time.

None of them could code a mobile game to save their life.

What your example is talking is a situation where a fresh off the press MBA is shoved in to a very specific field and they start just doing pure numbers and Excel management out of a management book without knowing how that specific industry operates.

Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.

Re: The worst programmer I know

#652

Post by theshrike79 »

snarf21 wrote: post #211
wonderwonder wrote: post #104

I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers. Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week…

Goodhart's Law - "When a measure becomes a target, it ceases to be a good measure"

My anecdote about this is a case where I was an external consultant in a company.

The management decided to base bonuses on "number of open tickets assigned to a person measured on day X". Smaller being better.

(Un)surprisingly I got a bunch of tickets assigned to me on day X-1 and they were reassigned on day X+1. I didn't mind, since my bonuses were determined by customer satisfaction =)

Re: The worst programmer I know

#653

Post by theshrike79 »

johnnyanmac wrote: post #487
worik wrote: post #465

Earlier quoted context omitted.

> Not exactly something to encourage Yes it is. Putting out fires, quickly, is very important. The problem comes later when the breathing sapce arrives to regularise the fix and replace the band-aid with good quality code. At this point no fire is burning, the problems are not immediately visible, and it takes very good management, right up the stack, to fix that sort of problrm. > Not exactly something to encourage…

>Because the band-aid with all its ugliness becomes the permanent fix because there is no revenue box to place the work in takes to fix it into Yeah, that's what I was getting at. Especially in my industry, we don't get too many chances to convince the product managers to "go back and actually fit the code". From a business sense, it's a great skill, but business realities equate it to the ability to plug up a dam wi…

I just do the boring thing and get it in writing somewhere.

"This will fix the problem for now, BUT it will make _everything_ harder in the long run unless we spend time to do it properly".

Then when they complain about stuff taking longer than it should I can just refer to the ticket/email/meeting memo and remind them that I did say so.

Re: The worst programmer I know

#654

Post by theshrike79 »

wizerdrobe wrote: post #378
spyhi wrote: post #265

Earlier quoted context omitted.

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.

This, sadly, needs to change.

The pool for experienced senior level talent won't grow unless _someone_ spends the resources to hire and train juniors.

The incentive being that they can keep the best juniors for themselves and let the others back into the pool for others.

Re: The worst programmer I know

#655

Post by jfil »

loup-vaillant wrote: post #580
lll-o-lll wrote: post #507

Earlier quoted context omitted.

It’s important to find/figure out what a company values and optimise for that. Once a reputation has been established, it’s then possible to go about changing things, but not before. I’ve seen too many stories of people optimising for the “team”, but losing their job or being looked over for promotion due to negative perception from those higher up. The opposite is also true, sometimes unfortunately. Once a good repu…

> It’s important to find/figure out what a company values and optimise for that. One important ingredient for this is to know many companies will actively lie about their values. Typical case is, everyone tells you they value quality and feedback, while in reality everything is rushed and actual suggestions are at best thrown away in the "later" bin. > Once a reputation has been established, it’s then possible to go…

> As far as I can tell I have no control over the initial condition

There is something: as part of the hiring process, arrange with your boss to get a warm introduction to the team. Make sure that your boss describes the challenges that led to your hiring, your qualifications (and that they're excited to have you on the team!) and present the vision of the positive future impact that you are likely to have.

I've benefited from these kind of intros when I was a consultant. The senior consultant would hand off the engagement to (junior) me by making me look like a star. Also, meeting people in person as soon as possible after you're hired boosts trust.

Re: The worst programmer I know

#656

Post by zdragnar »

koenneker wrote: post #644
zdragnar wrote: post #588

Earlier quoted context omitted.

I had a similar experience to yours. Back when I was the equivalent to what is now staff engineer, my team got a new boss. On paper, I didn't look amazing, but I was constantly helping people. My new boss admitted at our first review that he had written up a performance plan, but threw it out not long before. What happened was we just transitioned to an open office, and he got to see the line of people who would come…

Have you found a way to keep up with the "question answering"-part while working remotely? Did the culture around questions change compared with working from a shared office?

Switching to remote work also brought about a significant change in the types of teams I work with. In particular, I avoid larger companies, so there's fewer structured relationships between juniors and seniors.

That said, the challenge is getting over the hump of being proactive. I'm not sure if it was working in an office or the agency model of hourly billing plus time sheets, but I find people are far more likely to spin their tires and waste time until I finally convince them that they can ask me questions any time.

Perhaps there's something about working remotely that people feel the need to be more independent workers, I'm not sure. I'll initiate pair programming sessions and ad hoc design discussions to get the ball rolling, and encourage them to do the same. That tends to do the trick, though as I mentioned at the start, my day to day the past 6 years has had much less mentoring responsibilities and opportunities.

Re: The worst programmer I know

#657

Post by rramadass »

theshrike79 wrote: post #650
rramadass wrote: post #536

Earlier quoted context omitted.

Oh No! Good people amplifiers are domain/technical experts; Scrum Masters/Agile Coaches are neither.

Nope. The best amplifier I've met was hired as a junior coder to my team and was paired with a couple of 10x coders on a project with a client who was "hands-on" and loved to micro-manage, having been a software developer themselves a long time ago. The Amplifier's coding output wasn't that good, but the team as a whole was doing better than before so I investigated. Turns out the 10x guys weren't that keen on commun…

Your anecdote actually reinforces my comment. See my comment below for context - https://news.ycombinator.com/item?id=37378513

Your "Amplifier" is more like what is known as a "Field Applications Engineer" in the Embedded industry i.e. somebody with enough Domain/Technical/Marketing/Sales skills fulfilling a tangible need for the Business. They are more a "Business Process Optimizer" than a "People Amplifier"(a term i made up :-) who i define as somebody who can spark creativity/insights/viewpoints etc. which push others forward in their problem-solving endeavours. It is not merely removing hurdles/book-keeping/time management/liaisoning but an active role involving discussions/brainstorming/idea generation. This cannot be done without bringing some expertise to the table relevant to the problem at hand.

Re: The worst programmer I know

#658

Post by rramadass »

theshrike79 wrote: post #651
rramadass wrote: post #640

Earlier quoted context omitted.

You have missed the point. It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it…

There is a difference between "understanding the work" and "knowing how to do the work". I've had multiple Producers who "understand the work" of creating mobile games as a whole and understand how the team needs to work and interact to produce a result on time. None of them could code a mobile game to save their life. What your example is talking is a situation where a fresh off the press MBA is shoved in to a very…

>There is a difference between "understanding the work" and "knowing how to do the work".

True. However, the relationship between them need not be a "Total Function" but definitely needs to be a "Partial Function" to a certain degree. You cannot be completely divorced from the "How" and hope to have a good "understanding" of the system.

>Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.

This is precisely the point; domain/technical knowledge is needed to effectively Manage a project. This is independent of knowledge of techniques of Management. The problem today is that entire industries have been created out of thin air which posit that the latter is sufficient if one follows a certain process/methodology which is patently absurd.

Re: The worst programmer I know

#659

Post by vietvu »

By no mean I am the best dev I know, but I consider myself the best one with finding answer that I have met in person. e.g: fixing bugs, reading docs, even for things I have no exp about.

Anw when I was data engineer at a big corp data team, I was the one the 2 seniors there with 20 juniors, like fresh out of the colleges. So the juniors ended up ask me with everything since it was faster than googling them self. I still deliver things in my responsibilities since I can do it quick, also spend like one third of my times to mentoring them. Later, I found out that my manager thought I was slacking off, not working to my full potential.

Yes, the manager never payed attention to how the team worked. All the juniors thought that I was the reason the team was running smoothly and quickly. Ok, fine, I realized sometimes you cannot just work, you need to sell your work, even in your companies.

The nature of data engineer job is to ensure things run ok. So everything too well for a long time, then the higher ups might think it is easy. It might sound like bad thing, but when a bug happened, sometimes I let it be if it is not too serious, to let it rises to the higher ups. Of course being able to solve it quickly is a must.

Re: The worst programmer I know

#660

Post by CRConrad »

rramadass wrote: post #640
psunavy03 wrote: post #636

Earlier quoted context omitted.

It's basically a trope on this site for everyone to imply that everyone who doesn't have their fingers in code 8+ hours a day has a so-called "bullshit job," as if developers don't work for businesses which have to earn money, so forgive my skepticism. And yes . . . I do code.

You have missed the point. It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it…

> You have missed the point.

No, I think at least in large part, you missed the point.

> It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever).

As I understood _Bullshit Jobs,_ "adding tangible value" to some business that doesn't actually add anything of actual (non-monetary) value to the world is bullshit. There are whole industries that make billions of dollars, but everyone who works in them is still doing a bullshit job. (I often think I do.)

Post reply on HN