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.
My main confusion with this downtime is that neither their Cloud SQL nor Redis offerings managed to complete fail over despite my org having high availability enabled on both of those plans. Is there something I'm missing here? I would've suspected that failover would kick in for high availability instances and cause minimal downtime however its been almost 24 hours and our Cloud SQL instance is still stuck on attempting to fail over, not to mention that it comes at a premium. Wondering if anyone can help me understand what I'm missing or if the failover behaviour is not working. We've made our own workarounds in the mean time.
EDIT: Have found out from our ops team that the SQL instance recovered around 3am so it was down for approximately 9 hours -- which is still totally useless for something deemed HA.
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.
Not sure about the interaction aspect of the device, but it reminds me of the "Pico Siblings" required by the (now discontinued?) Pico project by my old lecturer which aimed to get rid of passwords[1].
I don't know about the art vs math question but, taking the math example, your code can be unsafe in the same way your maths can be wrong (i.e. maybe you start with a bad premise or your derivation is invalid). More generally I'd describe both of these situations as 'unsound' and actually they manifest themselves in the same way in both disciplines (an oversight, incorrect model, complexity, etc).
You might think that if you do maths on the computer, maybe it can help you keep things valid as you execute your derivations, and something similar can be done for coding. This is true, in maths/logic they have theorem provers and in coding we have static typing. Again they literally manifest themselves in the same way in both disciplines due to the Curry-Howard Correspondence[1].
You can also argue that in conjunction with static typing there are also linters, etc, but I anchor specifically to static typing in this example because of how directly it relates to your math comparison.
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 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.
> One of the benefits of HATEOAS is that it allows REST clients to be loosely coupled with REST services, in a way that APIs can change freely change
My point is that even though they're loosely coupled, the API actually cannot change freely because the actual consumer of the API, the business logic, is still tied to the API through the client. If your API changes and the client/browser is still able to traverse it fine, but your business logic breaks, does that actually mean that the API is free to change? I don't believe so.
Most of the APIs I use and build are best suited as RPC systems rather than hypermedia networks, so implementing the entire REST idea has never been immediately useful. Broadly the real consumers of RESTful APIs are not generic hypermedia clients (generalisation of browsers) which are able to traverse your flavour of hypermedia, but the things operating those clients. Most of the time, those “things” are dumb business logic applications that can’t explore the hypermedia to discover
new functionality and furthermore are not designed to do anything with it anyway.
If it is a human traversing the hypermedia however, they’re able to derive a lot of understanding about the API and its features, as if the API is self documenting, but that generally only occurs
during the development and debugging stages. After that the hypermedia is useless to the dumb business logic. Also I’m sure most humans prefer to browse the documentation on the alternative World Wide Web hypermedia network, as any good API would have documentation published there.
All in all hypermedia is mostly useful for intelligent consumers, so if that is not the consumer of your API and you suspect instead the consumer will be static business logic (the vast
majority of cases) then REST will not be particularly useful. As I mentioned an interesting use case would be bundling up documentation into the API itself and hyperlinking between that and related URLs, however the overhead is generally not worth it since you’re likely to do it better with documentation site.
> I use vim simply because it is ubiquitously installed on every linux and Mac system no matter what or where
This was also my initial reason for learning Vim so that I could comfortably write code on any machine I encountered, but the editing experience was actually really fast and enjoyable so I stuck with it ever since.
I'm guessing Epic wants the court to break down Apple's monopoly on app sales on iPhones, potentially by requiring them to allow third party app sales via alternative marketplaces, then swoop in with their Epic Games iOS marketplace and capture a big chunk of Apple's in-app purchase lunch. Considering the sheer size of Apple's revenue from gaming despite not being a game development company[1], I'm guessing that Epic has weighed up the expectency of proceeding with this legal battle and decided its worth the risk.
I mean if this is their plan and they pull it off then hats off to them. As a consumer I welcome healthy competition.
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.