Not to say exercise isn't important but... One minute physics[^] I just like quoting the choc bar vs exercise example. People, especially in the new year, tend to do it all from the start and fail. Start small and start with your diet. I've changed my diet this year and any day now, I'll be getting the cross trainer downstairs to take it to the next level. Yep, any day now :~

This used to happen at my old job with deploy instructions written in a Word document. Everything about the deploy was here and in order. Mainly to minimise the chances of any production down time, but it was also used to sync development machines after a major deploy (There was dozens of devs). Copy and pasting Web.Config entries from the word doc into a config file would cause frustration for everyone at least once. But Hey-ho, who really expects mickeysoft tech to play well with others, even family.

I don't fully agree that the person who writes the code shouldn't also write the tests. The only benefit I see is the person writing the test will be in a different mindset to the coder, which can lead to some tests that the coder wouldn't have thought of. The bad side is that it would take so long to have them bounce code and tests back and for until both were happy, I'd think it would cost more money than it would save. Also, you assume the person writing the tests have a complete understanding of all units of logic that go towards fulfilling the requirement. Even if the code was documented and we'll written, there would still be induction period for the person writing the test to get acquainted with the new code that the coder wouldn't face. It's all a cost/benefit ratio that I think favours the coder to do both.

Ideally yes, but I was in an office of over 30 devs, testers, PMs and a systems architect working on 3 seperate projects but all for the same system and they was great. Disclaimer - Previously us 30 IT guys were in a room with about 150 call center staff so my opinion my be a little bias.

I think the open office environment only really works on a department or team basis. I've been sharing with a call center (noisy AF), sharing with other devs and testers (both single and multiple teams) and now work from home. Sharing a work area with other like minded people feels like it was the most productive and satisfying place to work, especially when working to a common goal.

Management has to look like they are in control...

I agree, I've been a C# development for 9 years now and I've seen far more useless, misleading or just plain wrong comments in code than helpful ones. Adding comments is just another piece of "technical debt" that needs to be maintained with the code - and devs don't see comments as important as code. I think comments should be used sparingly to describe things that are not obvious from the code (like why you are trimming 7 characters from the input stream from that 3rd party service). Thumbs up for the others on the list 👍

That's not a unit test, that's an integration text. My previous job implemented a 80% code coverage rule on a system that had no unit test (or test friendly code) on there. So even if you changes a single character in a method, you needed at least %80 code coverage. Very mixed opionions on the usefulness but after a number of years and after we tied the tests into TFS's nightly builds, it really started to pay dividends. It's a real tough start but I'm all for it. I remember someone wrote a unit integration test that only worked the 4th time is was run because it needed the other tests to populate the DB with enough test accounts for it to work :wtf:

Tuesday! ... because its the furthest day away from another Monday.

Any code that has implemented some sort of source control shouldn't have any commented code. If your customer wanted to go back to previous functionality, you should review the source code history to retrieve it from there, it should even be wrapped up in a single check-in with all the dependencies that the functionality relies on. You can comment code during development to test other avenues, in fact, I think can use whatever coding practice you like while developing :-\ but it shouldn't get committed into the code base. Sorry if this comes across a bit sour, but I'm working at a place that used to use commented code as source control... They have source control now, but they haven't grasped the concept very well and the code is littered with obsolete, misleading and blatantly wrong comments :wtf: :mad: So... crime.

I would say if you are copying raw code, then yes, you need to understand it. Libraries on the other hand are something I do not fully study in depth before I use. Learn the interface and I'm away. Purist could argue that you should fully understand the inner working of all code in your system, but who has the time to do this in a commercial environment? BTW - big fan of commit strip, hit's the nail on the head with surprising consistency.