Don't know if this happens in bootcamps, compsci degrees or software edu. in general, but an excellent thing to teach would be how to refactor properly. Not trickery / code golf / algo games - but to take ~2000 lines of existing code and make it clearer, simpler & more boring ->

A lot of what you do as a working engineer is in between the edges of other people's thought processes. Sometimes, after a while, old processes become outdated in the context of the app's requirements and you need to work out how to properly, safely re-engineer for maintenance.

You tend to have to read a lot more code than you write, all things considered. Reading code well is a good part of refactoring well. Being able extrapolate what is definitely happening is key to replacing outdated, existing work with more effective new work.

Good code is easy to read, easy to reason with, clearly documented and low on redundancy. There's space for tiny, minified, hyper performant code but 80% of jobs on the web just don't need it - they need clear, quick, flexible, boring, documented code written for human beings

Being able to refactor excellently teaches:

> How to gather new requirements
> How to look at a whole system and extrapolate facts
> How to understand interplay between parts
> How to then reduce redundancies
> How to delete code (!)
> HOW TO WRITE CODE FOR OTHER DEVELOPERS (!)

The best code is no code. After that it is small amounts of clear, tested code. After that it is large amounts of clear, tested code. Slips easily, though. Before you know it you're surrounded by the pipedreams of other engineers trying to get raises lol.

As developers we should be suspicious of all code and try to delete as much of it from the Internet as possible while still making compilers, bosses & users happy and we should be supportive to both each other and people who work in non-technical jobs. This is our (my) mission.

Refactoring as a skill (RaaS lol) also teaches you that there are *very* few scenarios where you need to start from scratch on anything you are building and it's *good* to be able to build on other engineers' work and thought processes to turn out effective software.

(As a group or a pairing task, it also demonstrates very well how you think and work with other code and humans in a clear, practical and explicit manner.)

Asking one to explain why / how they refactored something is a good way to discover what an engineer thinks is important, what they know about good practices, and a general insight into their skill level. There is no perfect way to explain what you know as a dev but this helps.

You can also add good hands-on stuff:

> Tests passing before & after
> Updated comments

It's also nice as evaluation task. 'Make these 2000 lines simpler to reason about, with less redundancy & make sure the tests still pass. You can use the Internet, because it's 2021.'

This also teaches something else that I constantly need to remind myself of: there is no 'perfect', and 'good enough' is almost always more than sufficient. You can drive yourself mad obsessing over meaningless implementation details. That is very rarely a good use of time.

(Unless you're working at massive scale on extraordinarily demanding software. Then you already know all of this anyway.)

'Don't make perfect the enemy of the good', generally, is one of the most important things mid-level devs can learn, I think. Early career devs should try to write perfect code > eventually see it's not always needed > become a highly effective senior who understands trade offs.

(This is NOT the same as corner cutting or writing bad, flabby code. I don't believe in that, either. You pay for that later anyway, and always sooner than you think. What I mean is focusing on high-quality, regular output is way more valuable than 70 lines of artwork a week)

(Don't read 'tom thinks u should write shit code, force push to main and then go on holiday', from this.)

I imagine some businesses are doing this for interview processes. I'd approve of that. No code riddle shite or trickery, but a 'spend no more than 3 hours refactoring this 2000 lines of code and lets talk about your improvements together, and pair on a couple of small extensions'

When I own a software biz, if I see anyone interviewing another computer programmer with whiteboard stress games I am throwing both them and the whiteboard out of the window and the candidate is hired. Obviously joking I would only throw the whiteboard out of the window.

Anyway yeah. Maybe I can do a live stream on:

> Look at this old, sub-optimal code
> Analyse it and make a list of improvements
> Write the new code / delete the old stuff
> Write the new comments
> Write the new tests
> Compare old code vs. new code

If it would be useful!

Sorry for the weird thread, it is a stream of consciousness. Bye!