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

81–90 of 271 posts

Re: Beware of Developers Who Do Negative Work

#81

Post by hackits »

woah wrote: post #79
agentultra wrote: post #33

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.

Functional programming is nice, though I tend to find a procedural code easier to read than it's functional counter part. There is a place and time for mutation of state and their are other times when just simply duplicating data for clarity is much more straight forward.

Re: Beware of Developers Who Do Negative Work

#82

Post by toast0 »

flukus wrote: post #49
gumby wrote: post #47

I have one exception to the "convoluted code" developer. I worked with a guy whose code was pure spaghetti. Mostly write-only code. BUT: if a customer had a crisis he was the person to send. Amazingly quickly he would suss out the problem and get things running -- making the customer happy and rescuing the SLA. And he could explain what the problem was so someone else could implement it again, properly, perhaps in 10…

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

Re: Beware of Developers Who Do Negative Work

#83

Post by hacker_9 »

indexerror wrote: post #74
renolc wrote: post #44

Earlier quoted context omitted.

This is definitely true on both ends. At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue). Similarly at my current company, we had a product were the init…

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.

Productivity.

Re: Beware of Developers Who Do Negative Work

#84

Post by MAGZine »

Aeolun wrote: post #61
firebones wrote: post #58

Earlier quoted context omitted.

On the surface, I think you're describing fire-fighters (who are loved for solving high-visibility problems), but in retrospect, I think these are also developers with very high reading comprehension and reasoning abilities. That may not make them great designers and architects (though some are), but they can see code for what it is and fix it, as in "The Big Lebowski", "in the parlance of our times" (in other words,…

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?

Re: Beware of Developers Who Do Negative Work

#85

Post by yoz-y »

indexerror wrote: post #74
renolc wrote: post #44

Earlier quoted context omitted.

This is definitely true on both ends. At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue). Similarly at my current company, we had a product were the init…

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.

Re: Beware of Developers Who Do Negative Work

#87

Post by renolc »

indexerror wrote: post #74
renolc wrote: post #44

Earlier quoted context omitted.

This is definitely true on both ends. At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue). Similarly at my current company, we had a product were the init…

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.

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 different people. In that case, a language made specifically for expressive statements is significantly easier to deal with. That's not to say that I believe the opposite is true and that _everything_ should be done in programming space. I just think there is a better balance that can be achieved, and to default having everything in either category probably means you're not balancing correctly.

Re: Beware of Developers Who Do Negative Work

#88

Post by di4na »

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?

The other way around. If you can get out with doing it the wrong way, why even care about there being a good way ?

Re: Beware of Developers Who Do Negative Work

#89

Post by alkonaut »

indexerror wrote: post #74
renolc wrote: post #44

Earlier quoted context omitted.

This is definitely true on both ends. At a previous company, the tech influencers believed in the archaic "do everything in the database." While we were technically using the .Net stack, we weren't allowed to do any actual business logic in C#. Instead it had to all be done in MS-SQL procedures (or at least at much as possible with very little CLR glue). Similarly at my current company, we had a product were the init…

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.

> Can you explain why you feel that "do everything in the database" is archaic

I think it is because I want to be able to compile and test from end to end without having a certain database on hand. I consider the (specific choice of) DB to be an implementation detail, just like whatever file system the application might reside on once deployed.

I know this is an idealistic point of view and sometimes you end up with terribly slow ORM multi-join code where a stored procedure update might have been very simple - but that's an optimization I'd like to keep until it's actually needed because of the flimsy guarantees and poor integration of SP tooling (If I misspell something in a a stored procedure can I be sure it's caught on my dev machine without having to run through integration tests?, etc)

Re: Beware of Developers Who Do Negative Work

#90

Post by falsedan »

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?

More like, if you know English and Latin, why not blog in Latin, since it makes no difference to your ability to enjoy your posts.
Post reply on HN