Live data from Hacker News

Why Good Developers Write Bad Code: An Observational Case Study [pdf]

upedu.org

31–40 of 85 posts

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#31
I had to write bad code because sales and management usually dictate the timeline of the project.

As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented.

My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneath, they often times don't see the difference and when they explain to the boss that they might lose money, it's almost always option #2.

I hated being forced to do this so many times in my career, I started my own company.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#32
post #5

Earlier quoted context omitted.

I get really crabby about bad commit messages because on some projects, the commit history is the only 'Why' you ever get. Scratch that, on MOST projects that's the case.

There's nothing worse than a project full of bad commit messages. There was one project I saw that had a two line commit message, and there were 29,000 changed lines across 44 files. Who does that?

What was the commit message?

"Issue #27" is terrible. Something like (in C#/VS) "Execute CodeMaid against solution" would be perfectly fine.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#33
post #28
post #27

Earlier quoted context omitted.

I had a local git repo with a month's worth of commits. I hadn't pushed any of them so they were all _just_ local (though the head was constantly being uploaded to an online store). I got a new computer and when I was getting rid of my old one, it didn't occur to me to push all the commits or save the git repo. So, my next commit consisted of all the changes for that entire month.

but wouldn't those be represented as individual commits (just happened to be pushed at the same time)?

Sounds like he lost the local repo, and only the actual final state of the files was backed up. Thus, a single new commit representing everything at once.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#34
post #27

Earlier quoted context omitted.

There's nothing worse than a project full of bad commit messages. There was one project I saw that had a two line commit message, and there were 29,000 changed lines across 44 files. Who does that?

I had a local git repo with a month's worth of commits. I hadn't pushed any of them so they were all _just_ local (though the head was constantly being uploaded to an online store). I got a new computer and when I was getting rid of my old one, it didn't occur to me to push all the commits or save the git repo. So, my next commit consisted of all the changes for that entire month.

It sounds like you forgot to copy the .git folder that had all of the commit information.

If you make a commit, it would copy over with that, because it's written in that folder.

I'd wager that you simply copied the main files over and tried to re-commit.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#36

I had to write bad code because sales and management usually dictate the timeline of the project. As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented. My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneat…

> I hated being forced to do this so many times in my career, I started my own company.

It depends a lot on what your company is doing, but for the most part, you'll probably discover that cutting corners to save your short-term time is often the right thing to do.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#37

I had to write bad code because sales and management usually dictate the timeline of the project. As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented. My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneat…

[deleted]

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#38

I had to write bad code because sales and management usually dictate the timeline of the project. As an example: sales promises new customer feature X in one month and we will lose money unless it's implemented. My choice is to either: 1) Complete it the right way in double the time or 2) use hacks and cut corners to get it done on time. Since non-technical people just see the output and not what's going on underneat…

I will tell you, as someone in the same position, that even when you get all of the time you need, and you write elegant, beautiful code, in five years that code will probably seem clunky and outdated, and someone will ask you what the heck you were thinking when you wrote it.

Re: Why Good Developers Write Bad Code: An Observational Case Study [pdf]

#39
For me it's simple:

1. Lack of risk management 2. Poor project management 3. Allowing other to set my urgency (like deadlines but more psychological) 4. Not enforcing professional practises I know I should follow

3 and 4 are to all intents and purposes symptoms of 1 and 2

Post reply on HN