iovrthoughtthis

is this science to support back to the office?

I find this too concrete to be useful. I have a more principals / tradeoffs approach to code review:

Areas:

  - Readability - how understandable the code is
  - Maintainability - how the code enables the project to evolve
  - Risk - security, regulatory and other vulnerabilities
  - Correctness - whether the code does what you intended
  - Robustness - how well the code handles unintended circumstances
  - Performance - how resource efficient the code is

All of the above areas need to be considered within the context of the project and individual team members.

## Readability

Code is readable if it meets your expectations and surprises you only when there's something you don't yet know about the technology. We expect code to look like the code around it. To follow most, if not all of the technologies idioms. To use clear and informative names. To explain why deviance exists. To be as abstract as the concepts being abstracted are crystallised.

## Maintainability

Maintainability is the code's relationship with the wider team and time. You should be able to learn all you need to know to change, test and deploy code. You should be confident that any changes you make will not cause unintended changes elsewhere in the code. To make a change, you should have to touch as little code as the concepts being changed are crystallised. You should be able to debug an issue as easily as, the system the issue is in, is old. You should be able to track down and alter the changes that introduce a bug quickly. You should be able to learn why a change exists.

## Risk

Code is low risk if it accounts for, and where possible, mitigates the various risks to a project.

## Correctness

Correct code does as you expect and surprises you only when there something about the system you didn't yet understand. Validating correct code is as automated as the validations are frequent. Correct code is only as complicated as the concepts it models. Correct code is only as abstract as the concepts it models are crystallised.

## Robustness

Robust code handles unexpected circumstances safely, quickly and predictably. Validating robust code is as automated as the validations are frequent and as comprehensive as the failures are risky.

## Performance

Performant code is as resource efficient as the resources are expensive, but also as efficient as the development costs are cheap.

thus pattern divorces the code from the program ime

i appreciate that using an ide makes code navigation easier but i reject the notion that you should need one to navigate the code

TL;DR This is a bad example as we're mixing content construction with http service layer concepts. It should probably be more like:

    public class GreetingResource {
        @POST
        @Path("/make-greeting")
        public MakeGreetingResponse greet(final MakeGreetingRequest request) {
            return MakeGreetingResponse(Greeting(request.name, request.addendum));
        }

        public Greeting(string name, Value addendum) {
            if (addendum.isPresent()) {
                return "Hello, " + request.name + "! " + addendum.getValue();
            } else {
                return "Hello, " + request.name + "!";
            }
        }
    }

I think this is actually a little problematic. This handler is a likely location to mix http service logic with application logic and the interface exposed, via automatic parameter injection etc, implies the code in here should be application level but it's actually in the seam between then application and the http service layer.

Testing custom http service logic should involve mocking as it depends on objects and behaviours owned by the http service layer.

Code that we want to easily test for application level logic can be extracted into application level concepts.

Another social media power vacuum to fill. Who will take up the mantel?

RTO is a manager v labour issue.

100%

This is absolutely another form of layoffs. Google get the double benefit of 1) loose head count 2) only keeping dedicated* people.

They do loose people with the highest agency as they will be the first to leave.

* Those dedicated people could also just be most in need.

exactly

this is partially about wage depression

haha, it's absolutism v republicanism wearing new flesh!

whats old is new

dsl's are now little languages

the number one principal of a high performing engineering team needs to be that unblocking your peers is the most important thing you can do

if it's not, your peers will just invent work to feel useful while they wait for you to unblock them

teams that do this go fast, teams that dont go slow

you could probably use the managers salary to hire another floor employee to avoid such gaps in your particular example

but i think in general you are correct, but in reality i suspect many (but not all) managers dont actually provide any value, some even provide negative value

"Before starting the fundraising process, my first stop was to call up some VC friends of mine and ask them how to get things going."

ah, so it is

searching for a distinction between actively controlling a gui client vs passively controlling a interface-less client?

i would try not to fall prey to an entirely "rationalist" perspective here

you cannot predict the future and success is dependent at least as much on "luck" as it is on expertise

how have i never seen this!! :D

this is how everything echos through time, no joke

tea must terrify you!

powerful image!

this is not my experience. Jira is actually very opinionated about things in my experience. e.g. task hierarchies

it's just the pendulum of opinion swinging

the world needs yin and yang

we've had a good few years of self improvement being seen as good and noble. now for the return to mean

it will over swing the other way and productivity will return to the table in a different but similar form

like everything, this too shall pass

yup. we need to find a way to manage multiple owned borrows safely

a simple (not fully compliant) http 1 server from raw sockets usually gives me a good overview of the languages features and limitations

yeah, imo leadership and management are adjacent but separate things

you may be right but i think you're doing it wrong

how can you patent something with prior, public art?

is this human spam or some gpt3 spam?

1. giving feedback is a skill that almost no one learns to do 2. bad feedback will often cause problems that wouldn't exist if no feedback were given 3. not everyone is well placed to actually receive feedback

4 things help for me:

1. i like myself regardless of if this other person likes me 2. i will be fine, even if i fuck this up 3. every time im asked is an opportunity to practice, tweak something 4. write what you've been up to down

it's like rapping tbh. you learn snippets and lines that work and then you mix and match them for the context.

you don't want to be deciding word by word but phrase by phrase.