Live data from Hacker News

Beware of Developers Who Do Negative Work

blog.professorbeekums.com

131–140 of 271 posts

Re: Beware of Developers Who Do Negative Work

#131
post #117

Earlier quoted context omitted.

Even though CS fundamentals and contributing in teams are somewhat different skills, in my experience the terrible developers that contribute negatively to the project tend to be those that do not have a good grasp of CS fundamentals. I mean, some problems we are faced with are very, very challenging and if somebody can't figure out how to reverse a binary tree or do a FizzBuzz, then what can he do? Also I'm hearing…

Also if you restrict hiring to recommendations it's going to be even worse for your diversity. We can at least try to have a recruitment system that doesn't place too much weight on what people's faces look like or nebulous "cultural fit".

Other than warm-fuzzies, what are the benefits of a diverse workforce for a company? If you could eliminate the problem of bad hires by only hiring jewish black transwomen to the exclusion of anybody else, shouldn't you do it?

Re: Beware of Developers Who Do Negative Work

#132
post #106

Earlier quoted context omitted.

All of that apart from 5 is totaly wrong

Care to elaborate a bit? Especially, why do you think unit testing and debugging of SQL is not hard?

>Care to elaborate a bit? Especially, why do you think unit testing and debugging of SQL is not hard?

An SQL returns results directly in tables which you can check in all kinds of ways. You can create any number of temporary tables, with the same schema as your business tables, and check all kinds of invariants.

There's absolutely no reason why unit testing SQL should be harder than anything else, considering a single query as the "unit" of testing.

In fact, that's to the built-in checks, constraints and types a RDBMS has, you are freed from having to unit test all kinds of crap too (similar to having less to unit test in Haskell vs Ruby).

Re: Beware of Developers Who Do Negative Work

#133
post #79

The "convoluted code" gauge is a double-edged sword. You could also be working at a company with developers who have no experience with the benefits of functional programming. In this scenario it's those who write nested loops, branching if-statements, and mutating side-effects that are in charge and you're the bad developer for using fold and map. You could be seen as an elitist who likes to write clever, obfuscated…

Functional programming does have some useful syntax and principles that can make code easier to reason about. But a much bigger red flag is if a developer is so fixated on a certain programming philosophy or methodology that they don't pay attention to writing simple, good code.

If only there were on objective way to decide whether something is good code or not.

Re: Beware of Developers Who Do Negative Work

#134
post #119

Earlier quoted context omitted.

All of that apart from 5 is totaly wrong

What's the solution for source controlled database logic?

What's the problem with source controlled database logic?

Have your statements (including those that create stored procedures on setup, migrations, etc) on text files, and just load those into your Git or whatever.

Re: Beware of Developers Who Do Negative Work

#135
post #119

Earlier quoted context omitted.

All of that apart from 5 is totaly wrong

What's the solution for source controlled database logic?

You have an export file in your repo, containing all your stored procedures and part of the deployement process is to export the procedures to the db, updating as needed.

Re: Beware of Developers Who Do Negative Work

#137

Considering that the author writes on his resume that he lead several teams, it startles me a bit to see how easily he puts all the blame on the developer and none on the other team members (including him) and the management. The way I see it, as a senior developer or team lead it is your job to make sure that your junior level programmers are doing good work, and if they don't, you either help them to improve or (if…

Yes, I was reading that blog and trying to hear the voice of the frustrated junior dev who is blamed for everybody else's poor communication, who is not being supported and who is used as a scapegoat for the company's wider problems (structure, feedback, planning). Someone who spends their days wondering where it went wrong, why no-one is willing to work with them and thinking about how fast can they get out of there.

This article reeks of bullying, passing the buck and misplaced egos, imo. The solution provided is focused on how to avoid hiring 'problem' employees, unfortunately nothing about how to cope with the situation once it has arisen. People can change after the hiring process due to personal reasons, death, divorce, all sorts of things. The author's company does not sound like a good place to work staffed with nice people.

Re: Beware of Developers Who Do Negative Work

#138

I would fault this article for treating each developer as a being intrinsically good or bad. I've seen people I know are very talented (based on past work) become negative developers. Depression is a common cause. If they are underperforming they may react to their own self-disappointment by acting defensive and resisting change of the inclusion of anyone they think may judge them. I think there's many destructive fe…

Also devs can have different skill level in différents areas. One could be a rock star at the server stuff and do a poor job at the UI/web stuff (or any other possible version of this).

So that's another layer of variation to take into account.

Re: Beware of Developers Who Do Negative Work

#139

Considering that the author writes on his resume that he lead several teams, it startles me a bit to see how easily he puts all the blame on the developer and none on the other team members (including him) and the management. The way I see it, as a senior developer or team lead it is your job to make sure that your junior level programmers are doing good work, and if they don't, you either help them to improve or (if…

> let them go Erm, that isn't how corporations work. First, team lead doesn't mean manager, and even then in some companies, first and second line have very little to say. HR needs to be involved, etc. Which creates more work. There are the people who simply don't care. Contractors on a gravy train or outsourced people. I've been there, there is nothing you can do in this case. I think it's fair to say from your resu…

That's a valid point of course, thanks for pointing this out! I assumed that the organization in which you work is at least partially functional and that management has an interest in ensuring good working conditions, which as you say is not always the case.

But even if you're not in a position to do hiring/firing decisions there is still a lot you can do to make it harder for other people to do bad work. One of the easiest things is to agree on a standard for your codebase with the other developers, and create a process through which you monitor this standard (e.g. through code reviews).

If that's not possible due to resistance from management or a dysfunctional organization, you should consider leaving that position as soon as possible as it is not a good environment to work in (and as the author says, luckily there are enough opportunities for good programmers these days). But again, the problem here would not be the single bad programmer, but the setup of the whole organization, which is unfortunately much harder to fix.

Re: Beware of Developers Who Do Negative Work

#140
post #27

It's true that not all developers make positive contributions, however, I think that blaming "lowering hiring standards", as the author said, is a complete red herring. There is such thing as hiring without doing even the most basic test for technical competency: Last year, at a different job, I worked with a guy that though the best way to implement a CRUD service was an nginx plugin, and when faced with a real prog…

> I think that blaming "lowering hiring standards", as the author said, is a complete red herring.

I've seen it done, far too often. Management-only hiring interviews because devs were being "too stringent" and it was "time-sensitive". A guy who had "contributed to the Linux kernel", but his FizzBuzz implementation didn't work. Of course, management didn't notice, only by luck did a dev look at the whiteboard after the interview.

Or, even if they haven't lowered, someone slips through the cracks. They then usually bounce from team to team, happily collecting paychecks. Then, after they've been around for years, having worked on so many projects, management considers them senior somehow. Everybody thinks "can't be that bad if nobody has fired him", and thus firing never occurs.

Post reply on HN