Live data from Hacker News

Beware of Developers Who Do Negative Work

blog.professorbeekums.com

111–120 of 271 posts

Re: Beware of Developers Who Do Negative Work

#111
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?

I don't see that writing code to test SPROCs is that hard just have a set of inputs that match all of the use cases including all the edge ones run that through and check that the results on the db are as expected.

Debugging mm possibly slightly harder in that you might have to have a 3rd monitor for Toad or work Manager - but you code your sprocs properly in the first place you should not have that many problems that jump between code and sql .

Just saying its hard doesn't help in that case we ought to still be coding in GWBASIC

Re: Beware of Developers Who Do Negative Work

#112
Maybe the guy was really dumb or "awful" as the author puts it, but I think it is wrong to blame it all on the hired developer.

It's like in sports, there can be great players underperforming because of the wrong team / wrong coach.

When a team hires a person, there is a decent amount of time during which the hired person's code is not coherent with the hiring team's. During that period, the hired person must be trained so that the code can match the quality standards / spirit of the team. During that time, other devs have to mentor the new dev, which in itself is "negative work".

What the author is really saying here is "beware of the developer that needs training". Of course it'd be better if all new hires didn't need any training, but it is unrealistic.

Training is necessary for all new hires, not because people don't code properly, but because their coding style not necessarily match the hiring team. You can hire a very experienced developer who you feel spends too much time on testing, while your team has a more "move fast a break things" approach to dev. Or having people who are used use design patterns, because it worked in their previous workplace. There is always some time required to adapt.

Hiring a developer and have him check in 2 things in a period of 6 months is a failure of the entire team. If the guy was so awful, that should have been spotted in the first 2 weeks. And his "awful" code would certainly not have gone through to production.

Re: Beware of Developers Who Do Negative Work

#113
Interesting, just recently read about similar concept from Chris Hadfield's book "An Astronaut's Guide to Life on Earth". He puts all team newcomers intro three categories minus ones, zeros and plus ones. Basically minus ones will think they always know better and do not spend effort on familiarizing themself with existing system, they also ignore epistemological category of "unknown unknowns". Chris recommends always to strive for being a zero at first.

Re: Beware of Developers Who Do Negative Work

#114
post #82
post #49

Earlier quoted context omitted.

> Amazingly quickly he would suss out the problem and get things running -- making the customer happy and rescuing the SLA Probably skills they learned reading their own code. I've noticed it with other people, the ones he can quickly debug spaghetti are the ones that will create more of it. It's why they stick around, management likes them because the can solve problems, they just don't see the creation of yet more…

I might be one of these people. I've worked with enough underdocumented code/systems, I don't expect, look for, or provide documentation.(Exception: I provide documentation where there's a clear and stable boundary/interface another team will use)

I had this with the OpenStack API. It's so hilariously underdocumented that I've reverse-engineered it by poking at a Devstack and checking the HTTP requests in mitmproxy. After some time, even when I had to work with a new part of the API, I didn't even bother to check for documentation because just poking around was faster (and more reliable: one never knows how close the documentation is to the real deal).

Re: Beware of Developers Who Do Negative Work

#115
Good points. Regarding how such people come to influence, you have to remember a lot of people, especially in startups, are not hired through a process at all.

I worked with a guy for many years who was as described in this article.

He can't code and he can't do any math, despite holding a phd. He can talk about math and he can talk about code, but we're talking excel level skills when what you need is someone with a modern ML level skillset.

He made all the decisions about which trading strategies were worth pursuing and which ones weren't, despite the presence of plenty of more qualified people.

How could this be? First of all, the boss of the fund did not have the skills to judge who could write a trading strategy, and who couldn't. So he was stuck with recommendations from other people who also didn't have this skill, leading to this hire. He also relied on his bias towards people of his own ethnic group, which benefitted this chap we're talking about greatly.

Essentially, broken feedback. Someone who can't judge relying on the judgement of someone who isn't competent but has his ear.

I'm sure this has happened to a lot of folks. Probably you need a somewhat larger organisation for there to be enough informed people to point fingers, and you need some luck for the culture to be such that a complaint would actually come through rather than be suppressed.

Re: Beware of Developers Who Do Negative Work

#116

Earlier quoted context omitted.

while I'm not arcticbull, I worked for a period of time with somebody who was a minority and completely horrible at their job. Everytime my boss tried to get him fired, HR pushed back

Solution is easy there -- promote away.

Dilbert's Principle?

Re: Beware of Developers Who Do Negative Work

#117

> So if the cost of a developer who does negative work is so high, how do they get hired? Part of it can be explained by an interview process that needs improvement, but a less talked about part is the temptation to lower hiring standards. I've seen plenty of people who can reverse binary trees or fizzbang etc who are terrible additions to teams and do "negative work". That's because having a grasp of CS fundamentals…

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".

Re: Beware of Developers Who Do Negative Work

#118

Good points. Regarding how such people come to influence, you have to remember a lot of people, especially in startups, are not hired through a process at all. I worked with a guy for many years who was as described in this article. He can't code and he can't do any math, despite holding a phd. He can talk about math and he can talk about code, but we're talking excel level skills when what you need is someone with a…

I work in finance and I've seen the same thing happen. I guess it's more common than people realise.

Re: Beware of Developers Who Do Negative Work

#119

Earlier quoted context omitted.

Logic in the Database has the following issues: 1. it doesn't work well with source control 2. deployments, rollback, replication, synchornization - they don't work very well with db procedures 3. unless you connect directly to the db, then you must have some logic on the serverside, usually you end up replicating logic from the db to the serverside 4. Databases languages (even advanced ones like PL/SQL) are not expr…

All of that apart from 5 is totaly wrong

What's the solution for source controlled database logic?

Re: Beware of Developers Who Do Negative Work

#120
post #87

Earlier quoted context omitted.

Absolutely. SQL is great, and having the DB just give you the correct data from the get go is convenient. But in the case where complex logic is necessary, SQL is much more difficult for correct implementation than something more expressive. You _could_ delve into cursors or long merge statements or what have you, but in business logic specifically, the code will be read and altered numerous times by several differen…

And your point is? yes sometimes you have complex business logic but throwing way all the benefits of using a RDBS is a sign that your developers cant hack SQL properly.

[deleted]
Post reply on HN