71–80 of 85 posts
Earlier quoted context omitted.
This just reminded me of whatthecommit. IIRC they get these from actual commit messages; if they do, there is no hope. :-) [0] http://whatthecommit.com
https://github.com/janraasch/javascript-commitment/blob/115d... I'd assume the keys are the commit hashes? Now how to search github for them...
TL;DR key recommendations: - Once a project is completed, the team must ensure that the “What” and “Why” of each software item are properly documented. - In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams. - Make sure that the development team is aware of the CMMI-ACQ or ISO12207 processes for negotiating with third parti…
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.
Earlier quoted context omitted.
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.
So, there's no such thing as good quality code that saves time in the long run? So we should just give up and hire some cheap overseas contractors because the result will be the same? To anyone except an MBA running a software project for the first or second time, that's pretty obviously not true. (Some people, when they realize this, do "additional process will be mandated until quality improves".)
This is usually one of the fastest ways in an interview to tell how experienced someone is. Younger, less experienced programmers are dogmatic, but their view is extremely limited - they believe defiantly in the current coding practices, but haven't yet learned that their dogma is just the latest, and will be replaced in short order.
Hey, I was once one of those dogmatic kids, too.
Earlier quoted context omitted.
Are you implying logic driven companies exist?
yes, they do. I'm contracting (in germany, if that's important) and about a third of the companies that hire me have high or very high standards when it comes to avoiding technical debt, adherence to sane development cycles and clean code. So yes, there are those companies.
Earlier quoted context omitted.
So, there's no such thing as good quality code that saves time in the long run? So we should just give up and hire some cheap overseas contractors because the result will be the same? To anyone except an MBA running a software project for the first or second time, that's pretty obviously not true. (Some people, when they realize this, do "additional process will be mandated until quality improves".)
I'm not clear what your last sentence means at all. You write the best code you can at the time, but a dogmatic approach - even the one that you think will save so much time in the long run, will likely be completely useless within a few years. It sucks, but that's what happens. This has a positive spin, too - you will be much less likely to adopt flavor-of-the-month programming tactics until you really vet them, unl…
You're right though. And it's a balance between technical debt incurred having not enough time (hacky shortcuts) vs technical debt incurred from having full freedom (overengineering of unnecessary layered abstractions and indirection).
It's a tightrope and we're always going to stumble somehow. In retrospect, we tend to focus on the stumbles (wouldn't do that now!) rather than the fact that we actually got across the canyon and delivered business value. A natural bias - we discount the fact that we're making new mistakes even as we look back and criticize our past mistakes.
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?
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?
Guilty as charged. Or maybe 'nolo contendere'. I just dropped 5kloc, 6 weeks work, into a repo with the message "Initial commit" I'm currently working on the changes that will actually document what is otherwise a walk of code. The road to hell is paved with good intentions.
Earlier quoted context omitted.
I'm looking at a commit message from one of my clients today, which is just "Not, new bins, cant stop bins" and a check-in of several hundred dlls generated as build artifacts. Six days later another developer at the client checked-in a commit that removed all of the dlls, with the message "remove BIN folder". Some other examples: "Fixes to make work", "Left Over", and their most common message " ". They're nice guys…
I have to admit, I've made number of commits with "." as the message. No excuse, beyond it usually being a minor change well documented in the code ( I always write comments ) and me being utterly buried under work... You know, start the day with 20 things to do, crack off 4 of them and have 23 things in queue at the end of your day. The "." was sort of a placeholder for "Fuck This, I'm ready to quit." ( and I did ev…
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.
IMO most of your "why" ought to be code-comments, not commit-messages, because most of the time people say: "Why is this code this way" as opposed to "Why did this specific transition occur in the past".
There are man times when I have seen a crappy piece of code that I wrote a while ago, and decide to "tidy it up". The I test it, then remember there is a strange edge case that required me to write it the "crappy" way rather than the clean way. It always gets commented the second time.
Earlier quoted context omitted.
> 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 .
Bullshit. Most of the time the corner cutting is done solely because shithead sales drones make promises without consulting engineering in the slightest. They get a huge commission for getting the sale and go home at the end of the day. We have to put in more late nights to cover for their asses, and we barely get anything for a raise because of that one time we weren't able to meet sales physically impossible promis…