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

481–490 of 668 posts

Re: The worst programmer I know

#481

Post by madeofpalk »

vegetablepotpie wrote: post #311
crazygringo wrote: post #287

Earlier quoted context omitted.

> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns. I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds li…

I think what the GP means by “gaming” the system is that the teams did all the technical activities of scrum without providing much or any business value. The issue with scrum or any process that involves estimating is that every software project will inevitably have some risky element or difficult to estimate task that is essential to the execution of the project. Scrum will incentivize teams to avoid the essential…

“Story points” help you predict your work in the future. Knowing what and when you deliver can be valuable!

Say you’re developing software for the next Super Bowl broadcast - it’s useful to know whether you’ll deliver what you said you would. If it’s looking like you can’t, you can start to make educated decisions about what work to cut and get a better idea of what you actually will deliver.

Re: The worst programmer I know

#482

Post by Tao3300 »

crazygringo wrote: post #287
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…

> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns. I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds li…

Stress free and delivering at a predictable rate. Nailed it.

Re: The worst programmer I know

#483

Post by quickthrower2 »

ssss11 wrote: post #464
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…

I did an internship during uni as an electronics technician repairing handheld, vehicle mount rugged terminals, and base stations (rf network controllers before 802.11 arrived). Each repair job had the same priority but some were much simpler than others - one month I thought I’d take the base station jobs to learn and because no one else was repairing them. They took longer to fix but obviously were more crucial to…

So without someone like you they would literally not repair some units? I guess they chuck and replace them?

Re: The worst programmer I know

#484

Post by johnnyanmac »

lolinder wrote: post #434
johnnyanmac wrote: post #248

Earlier quoted context omitted.

>I was actually much more impressed by the latter skill — among other reasons it’s simply rare Not exactly something to encourage, but it sounds like he has experience in competitive competitions, where generating code to a problem on the fly is necessary. It's not something you can't learn yourself, but rote memorization of common problems and solutions (to the point where you can mechanically type down some algorit…

Don't competitions usually have completely different kinds of problems than what you typically run into in production fires? When I think of competitive programming I think of algorithms and puzzles, not network errors and data corruption. In my experience production fires are rarely put out by rote algorithmic knowledge, the skill is more having a detailed knowledge of the inner workings of every layer of the system…

Yes, it's not the full equation. But that type of environment gives you a mindset that isn't present in most other types of coding. The ability to think under pressire, identity the fastest solution, and store a number of approaches in your head should you encounter dire edge cases.

.

>the skill is more having a detailed knowledge of the inner workings of every layer of the system so that you can come to the right conclusion

Yup, and that's transferable skills from competition coding. You're not juggling algorithms in your head per se, but you juggle whatever tribal knowledge needed as options to cycle through. That combined with the above mindset can lead to such skills.

Re: The worst programmer I know

#485

Post by zerbinxx »

reneherse wrote: post #187
jongjong wrote: post #119

Earlier quoted context omitted.

I guess maybe in 10 years I'll be working with 30 year olds who understand and value of that approach as I do today. My current reality is that I'm a 33 year old working with 20 year olds who think they're geniuses who are going to take over the world in 5 years; from that viewpoint, I'm essentially a failed engineer because I didn't build a Facebook, Uber or AirBnB even though I had 10 years to do it.

I'm curious what type of company has these team demographics. Startup, agency, SMB, bigcorp, academia, or?

Usually this kind of thing comes from “trying to keep costs down” at a poorly funded firm, usually startup-ish. I’ve worked places where the oldest engineer was 30 and it’s rough, quality and stability just aren’t in the average 25 year old’s toolkit.

Re: The worst programmer I know

#486

Post by quickthrower2 »

The problem with the story is there is a reasonable solution for the bean counters: you log time against tickets you work on or help with. Then maybe prorata the points to the hours.

The issue now is of course you are just incentivising taking overestimated stories. This cat and mouse never ends. Crucially you are punishing/removing the glue people that do the stuff not specified that needs to be done. So now you need every little thing on the board. And a lot of time on arguing about what should be on.

It is worse when the tasks allowed on the board have to be agreed by a committee that meets on a Wednesday. Not joking that has happened! But that is another story.

Re: The worst programmer I know

#487

Post by johnnyanmac »

worik wrote: post #465
johnnyanmac wrote: post #248

Earlier quoted context omitted.

>I was actually much more impressed by the latter skill — among other reasons it’s simply rare Not exactly something to encourage, but it sounds like he has experience in competitive competitions, where generating code to a problem on the fly is necessary. It's not something you can't learn yourself, but rote memorization of common problems and solutions (to the point where you can mechanically type down some algorit…

> 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 with a cork.

Re: The worst programmer I know

#488

Post by bluecheese452 »

bratbag wrote: post #427
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…

Points are a relative value. If its 10 points a week then you estimate based on the assumption that 2 pts is a days worth of work. That, coincidentaly, is what ours roughly shakes out to be. Sounds like the stressed teams were lacking in common sense.

What happens if you underestimate one time? You get a pip. Better to overestimate.

Re: The worst programmer I know

#489

Post by emodendroket »

grumple wrote: post #452
cellularmitosis wrote: post #436

Earlier quoted context omitted.

And how would an experienced cowboy handle this situation?

Drag the work out for years and fuck around while collecting a paycheck commensurate with the work completed. Let the company hire the outside contractor. Then leave, become an outside contractor and you can be the benefactor. Save exceptional work for small companies that will reward it or your own startup.

If it’s a small company your energy is better spent ingratiating yourself to the inner circle, which doesn’t necessarily entail being effective.

Re: The worst programmer I know

#490

Post by ramraj07 »

tfgg wrote: post #261
Erikun wrote: post #25

Earlier quoted context omitted.

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…

Harry Nyquist isn't exactly an unknown engineer who doesn't have his own achievements, though - not sure why people are saying he would be fired in a modern company!

He doesn’t have his own achievements?

I have heard of the Nyquist frequency, the nyquist limit, the nyquist sampling rate and the Shannon nyquist theorem.

As far as I know no other individual has had this many “things” named after him.

Post reply on HN