dozzman

The critical objective either of these approaches is aimed at achieving is helping you _think deeply_ about the problem; how that is best done largely depends on the software engineer.

I feel design docs are a way to ensure that you indeed think through a problem as much as they are a tool for peer review. If you wen't through a fairly standard educational system, it's not unfamiliar to use writing as a way of thinking more deeply about a problem and communicating those thoughts with others (namely your teacher) -- a design doc is no different. This can fail when design docs are written as templated box-ticking exercises and address more superficial technical questions than the core problem of course; it actually needs to address the problem and that is very contextual in my experience.

However some folks are just better at solving problems with a more hands-on approach, in which case throwaway code may be more effective. If that is you then go for it, though its likely you'd need to still need to write _something_ to either document changes or communicate your decisions/trade-offs with the rest of your team.

Fundamentally just do what allows you to solve problems best and take into consideration how to best work with your team. There is no one-size-fits-all solution to _thinking_ and broadly no-one cares how you work (I believe, I mean I certainly don't) if you're efficient, communicate well and get the job done to a high standard.

There is also 'say' which is great if you need to step away from a long running command, in a similar fashion to ringing the terminal bell but with more context.

The whole region wasn’t down though, only zone europe-west2-a so AFAICT high availability should’ve covered this particular instance of outage.

yo its the UFO mouse that got me

I can also do this. I do it as eye exercises when I’m staring at screens for a long time.

This was at near the top of the front page around half an hour ago and now it has disappeared... What happened? Is this being filtered for some reason?

I also would have agreed with OP 5 years ago. Working in a leadership capacity for a prolonged period has emphasised the human side of coding, that is working in a team and respecting your colleagues’ freedom to think independently. IMO it’s far more important to maintain a strong and happy-to-work team than a marginally more aligned-with-my-own-thinking codebase.

> ... then you're doin' it wrong.

100%. Its mind blowing that this could possibly be considered without batting an eyelid.

If you can, commit wholely to a parsing formatter and plug it into your CI pipeline. I've come to realise over the years that its not style I care about per-se, but consistency. With a parsing formatter and an opinionated linter, you're pretty much covered automatically across all development and developers.

I learned vim so that ostensibly I could fire up an editor and begin coding on pretty much any linux box I come across.

This is essentially a solution to that goal, multiplied across any device with a web browser.

I think quashing divisive conversations in the workplace is generally a healthy thing to do for the well-being of your employees, however Facebook has put itself in a unique position which also makes the move hypocritical.