majikandy

Over time the digital dials go a bit rubbish and sometimes jump up and sometimes down and all over the place as you try to dial it up. I have to revert to using beep beep beep on mine to build up the 30seconds.

And adding after market vibration motors to the 3210 since they decided to leave it out of the UK model. I still have mine.

I can’t say I never have taken a role with a stupid coding challenge (because I have) but often you’ll go for 4 or 5 interviews maybe 4 having coding challenges. At least one role will end up having 5 stages! At least one will end up being just a 15-30 mins chat with no challenge, with either an instant offer at the end or a phone call from the recruiter 20 mins after you leave the interview.

Inevitably I end up taking the one that was just a short chat.

Not if you rewrite/change the tests first, since you know the code currently works and you are safe to refactor the tests. Equally you are safe to change the tests to define the new behaviour, and then follow on with changing the code to make it green.

Actually it is pretty common to have 100% coverage with some extra redundancy too (where some things get accidentally covered multiple times). Striving for 100% is indeed nonsense, but having 100% coverage is usually accidental in clean code that you want to work, and merely a by-product of TDD.

I strive for working code. Sometimes I miss something in the TDD cycle and don’t have 100% and it is that which usually comes back to bite you.

I have never found 100% test coverage has bitten me, dogmatic or otherwise.

This isn’t true. Many people like being subscribed to content they actually want. I know I do! If I’m on the list, email me.

Read the book if you haven’t, it’s all in there. You’ll get much more benefit than finding out about the supplements I suspect. I recall something about him introducing himself to people as a drug dealer when asked what he did for a living.

Probably more simply in kinetic and sound energy with water as it rumbles through the pipes and vibrates the pipes and barrels a bit.

Yes this is the exact explanation I give. Mentally pick 2 doors, but say out loud the other 1, when offered the switch you take it as it means you are back on your secretly pre-selected 2. Hence 2/3 chance by always switching.

I wouldn’t say Standup is terrible but one where you go round the room giving updates is almost useless. It’s not just you, most developers can do 8 hours work in an hour if they aren’t interrupted with meetings.

Spot on! I’ve also been developing software for over 20 years and my estimates have never improved. I think an order of magnitude is the only reasonably useful estimate, which can then feed into the question “is it worth doing it or not?”

Benefit for employee: recognition for out of hours coding, learning and contribution to society.

Benefit for company: employees reporting hours working which would normally be invisible (Spotting burnout, keeping company project focus etc)

Sounds like a brave but sensible move and an idea I hadn’t heard before. Also makes business sense to that company.

You are an excellent writer, so funny and gripping. I suspect writing is your true calling in life. Lol @ what on Earth is that oven? :)

So true. You have to google to find it, finding it on the amazon site directly is much much harder.

There is, it will save off whichever username you use when you sign up eg facebook@domain.com - works well for me.

Make the changes smaller and more valuable and do it on trunk.

I agree with you entirely but I can also see that the strategy mentioned could be a good bridge (for those who currently litter code with comments) to a better world where comments are rarely needed.

Well said, I was cringing when I was reading the bad advice and you addressed the points very well.

It is so frustrating to hear when someone thinks commenting more and adding humour is somehow cleaning up the code. But to then hear that they are teaching this to juniors just hurts so much.

Simpler advice to juniors would be to read Clean Code by Robert C Martin, apply some of those techniques and then politely ignore “more experienced” developers who think writing humourous essays as code comments is a good thing.

I’ve even heard phrases banded around like “the more comments the better” - I mean seriously WTF.

I like the analogy of...

When in an unfamiliar city, having no map at all is much better than a map that you have no idea whether you can trust or not. Code comments are absolutely that untrustworthy map, doesn’t matter how many code reviews or convoluted PR process takes place, you still need to read the code to know the truth so more effort making the code communicate is the key to maintainable code. Simple things like good variable names and grouping behaviour into functions at the same level of abstraction can completely negate the need for comments.

Comments have their place, but should be the exception not the norm.

I’m just trying to be absolute on the fact that incremental change of a single running system is more efficient and shouldn’t be confused with ‘rewrite’ projects where a second system, that is not used by the business yet, is developed while the business continue to use the ‘old’ one.

Calling incremental improvement a form of rewrite gives it a bad name :)

I’d argue that rewrites that are a second system that (hopefully) eventually get deployed once the features exceed current system is not incremental at all, but is instead Big Bang.

Even if the features of second system are built incrementally, if the business aren’t using it until it is finished then it is Big Bang.

Finally, can’t believe I had to read this far down in the comments to find a reference to clean code.

So true.

Are you serious? Almost every codebase that has comments has code that doesn’t exactly match the comments. Main obvious reason being that the comments aren’t executed whereas the code is. Sure meticulous attention to detail could keep the two in the sync. But you are suggesting that they have always been in sync for any code you’ve looked at?

As someone who is clearly a fan of comments, are you saying you’ve never modified a comment to make it more accurate to what the code is doing?

Commonly referred to as rule of 3. Write it out in full twice, on the 3rd time it must be a real abstraction, therefore refactor.

No comments are good comments.

Incremental rewrite isn’t a rewrite at all. It is the better choice though. It is worth noting that refactoring and improving an area of the code without a need to change it or build new features on it is also wasteful.

I can’t believe this has been greyed out. Absolutely well said. Self documenting code all the way, what a ridiculous place to hide documentation.

Agree!

Best comment I read so far on this. Taken a stage further, a well written codebase of self-documenting tdd’d clean code and commit messages become moderately useless. For all the effort they take and the rare occasion they aid in finding something useful, a completely blank entry for every commit is arguably more efficient. In the spirit of it only taking a few seconds whilst your head is in that space, a short brain dump of what it is in any format you like is an excellent and efficient choice.

Why read the code when you can read the out of date comments! /s

In my world, the test suite is a better “why” than code comments.