Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beware of Developers Who Do Negative Work

blog.professorbeekums.com

Post reply on HN
Print view View original

101–110 of 271 posts

Re: Beware of Developers Who Do Negative Work

#101

Post by lostboys67 »

yoz-y wrote: post #85
indexerror wrote: post #74

Earlier quoted context omitted.

Can you explain why you feel that "do everything in the database" is archaic? A lot of logic (especially authentication logic) can be put in the database only. Not to mention that I won't trust anything that only has application level security, and nothing at database level to check/limit it.

From what I gathered one of the biggest problems of stored procedures is that they do not play well at all with source control and associated tooling such as code review.

Rubbish you can check in your sprocs into a source control system along with the Database schema I never had any problems at BT when we did this.

And why can you not code review your sprocs?

Re: Beware of Developers Who Do Negative Work

#102

Post by waldfee »

Illniyar wrote: post #91
indexerror wrote: post #74

Earlier quoted context omitted.

Can you explain why you feel that "do everything in the database" is archaic? A lot of logic (especially authentication logic) can be put in the database only. Not to mention that I won't trust anything that only has application level security, and nothing at database level to check/limit it.

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…

4, 6 and 7 are my main problems with this.

i occasionally have to work with a big application which is essentially written 100% in sql. you simply can't easily change parts without testing the whole thing from start to finish because automated testing at a granular level is horrible. and sql does not lend itself to encapsulation, it does everything to make it hard to break stuff down to manageable pieces

and in sql everything you do is just so complicated, tons of boilerplate stuff you would not have in a real programming language. it's called "query language" after all, not "programming language". so don't use it for that

Re: Beware of Developers Who Do Negative Work

#103

Post by djrobstep »

yoz-y wrote: post #85
indexerror wrote: post #74

Earlier quoted context omitted.

Can you explain why you feel that "do everything in the database" is archaic? A lot of logic (especially authentication logic) can be put in the database only. Not to mention that I won't trust anything that only has application level security, and nothing at database level to check/limit it.

From what I gathered one of the biggest problems of stored procedures is that they do not play well at all with source control and associated tooling such as code review.

I just tried to commit a stored procedure to git and it seemed to work.

I then asked a colleague to review it. This also worked.

Re: Beware of Developers Who Do Negative Work

#104

Post by lostboys67 »

Illniyar wrote: post #91
indexerror wrote: post #74

Earlier quoted context omitted.

Can you explain why you feel that "do everything in the database" is archaic? A lot of logic (especially authentication logic) can be put in the database only. Not to mention that I won't trust anything that only has application level security, and nothing at database level to check/limit it.

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

Re: Beware of Developers Who Do Negative Work

#105

Post by walrus1066 »

bad_user wrote: post #73
matt_wulfeck wrote: post #66

> 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…

I find a lot of CS education is not applicable to most SE roles, as they operate at a higher level of abstraction.

I've never had to implement a binary tree, if I did, I would be reinventing the wheel.

A lot of the necessary skills are hard, if not impossible, to teach in higher education. Mainly because there, you tend to be given an exact, unambiguous specification. Whereas in the commercial world, I've never seen that to be the case, the developers role is to collaborate with the business to nail down the specifics of a high-level business goal. Implementing the code is the easy bit :)

Re: Beware of Developers Who Do Negative Work

#106

Post by mmoroz »

lostboys67 wrote: post #104
Illniyar wrote: post #91

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

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

Re: Beware of Developers Who Do Negative Work

#107

Post by davidgerard »

userbinator wrote: post #28

An even more egregious form of negative work is a developer who is stuck using out of date programming practices AND has a large amount of influence at a company. At the other extreme is the developer who is so entranced by "newer is better" mentality that they rewrite everything in an attempt to conform to "latest best practices", increasing complexity massively while introducing a bunch of bugs and huge dependencie…

One of my official reasons to read HN at work is to get advance warning of awful new trendy technologies.

Re: Beware of Developers Who Do Negative Work

#108

Post by flukus »

MAGZine wrote: post #84
Aeolun wrote: post #61

Earlier quoted context omitted.

I mean, if you understand spaghetti code just as easily as any other code, why wouldn't you write it? It would make no difference to them.

What is this reasoning? If you know the right way and wrong way to build a bridge, you'd build it wrong, because it makes no difference?

It's a lack of reasoning, if it's not causing any issue's why change? The rest of us write good code because we're to dumb to read bad code.

Re: Beware of Developers Who Do Negative Work

#109

Post by walrus1066 »

Yhippa wrote: post #53
sna1l wrote: post #32

Earlier quoted context omitted.

+1 to this. I used to work with a guy like that and it created a ton of tech debt. He would write new services using a new technology for each one, not to documenting or maintaining any of them.

What's sad is that it looks great on his or her resume to do that. That developer might leave a trail of carnage but they don't care--on to the new shiny job for them. It never catches up.

100% this is a huge flaw in our industry, it applies at the highest level (CTO, architect) too.

In a friend's company, their CTO has mandated a rewrite of the backend in Clojure, and that it should be as asynchronous as possible.

Low and behold, the devs aren't familiar with the language, and the async has resulted in a host of heisenbugs, that are hard to reproduce.

On the CTOs resume though, he would show how he got the shiny new architecture rewrite, any problems were the devs fault.

Post reply on HN