Symmathecist,
@honeycombio
. Tweets are mine, license CC0.
@jessitron
@hachyderm
.io pronouns=she/her “There is always more to discover if you pay more attention.”
Software is not a craft.
Nor is it an art.
Nor is it engineering, or architecture, or anything we've ever before.
I now have words for what development is: the practice of symmathesy.
When we rush development, skip tests and refactoring, we get “Escalating Risk.” Please give up the “technical debt” description; it gives businesspeople a very wrong impression of the tradeoffs.
From
@Janellekz
#deliverAgile
Don’t organize code according to its job title (model, view, utility); sort it according to its purpose (feature).
This reveals interdependency between features, and finds service boundaries for later.
“Software architect” is out of fashion
“architect” implies “design (mostly) before building starts”
We need design in software dev, design that never stops
People.
There is a difference between a backend and an API.
Taking the endpoints that you wrote for your site, slapping some documentation on them and publishing it
does not make an API.
Once a company reaches thirty people or so, the context starts to split: founders have the contextual knowledge of “why”, while newer hires only have the “how”
— so how can anyone make good decisions?
~
@estherderby
#uberconf
`git push --force-with-lease`
It's the new "do things right" flag for force-push.
Where by "new" I mean 2015 and I just learned about it.
Becoming an expert at something and staying an expert are two different things.
“The director said ‘I’ve heard nothing but good things about you.’
I wish someone would say those good things to me.”
- a first-year dev
Say something encouraging to your less experienced compatriot today. Programming is hard.
Software is never done until it’s out of production.
Instead of seeking a “definition of done,”
let’s define “enough.”
Enough on this feature, time to shift our focus again.
Not a developer: blogs in Wordpress
Junior developer: writes their own blog site
Developer: writes their own blog site framework
Senior developer: uses someone else’s blog site framework
Staff developer: blogs in Wordpress
“so that we have a single process for the entire organization”
is a death toll of software.
This is how large organizations slow themselves.
Unifying process gives every change a wide impact, and that means change must be slow.
Doing a change and a refactor at a same time puts a lot in your head.
It's like carrying all the groceries in at once: you feel powerful, until the cans scatter all over your floor.
also, you left the back of the car open.
one lesson from functional programming:
when ya got some data and something to do with it, DON'T just do the thing.
imagine a form of the data that would make the thing easy.
Transform the data, then do the thing.
I call this "cook your food, then eat it."
current status;
writing a program to help me write programs to change a program that changes a program that helps other people write programs to change programs.
Development gets harder over the years
because the problems that were just a lot of work have been abstracted away
leaving us with the hard questions, where “correct” is not obvious and context is crucial.
Understanding code is usually about understanding history - and having empathy for people in the past.
In commit messages, I try to have empathy for people in the future.
@boblail
Microservices are an excuse for bounded contexts.
Because having two classes called "Order" in the same program seems silly, and yet each department toootally needs to model Order independently.
A definition of done at Microsoft:
“Live in production, collecting telemetry that examines the hypothesis which motivated the deployment.”
@DonovanBrown
#deliverAgile
Yes! Start with “how will I know this is delivering value”
Code is cost, and production code is by far the higher cost.
If you can write more support code (tests, automation, developer tooling) in order to write less&better production code more smoothly,
Win!
* Code is a cost. All code. Always. Even packaged software.
* The asset is business capability.
* So the goal is to achieve that capability with the least code.
* The overriding metric is to sustainably minimise lead time to business impact.
by
@tastapod
The REPL is like unit tests that don’t stay
and I like unit tests that don’t stay
because I don’t need them once my high-level ones work, and they can prevent refactoring.
OMG I just figured out how to change something in CSS on purpose! Like with reasoning and theories, instead of clicking until something worked and then hoping it stays working
This explains why performance reviews, career tracks, and promotions rub me very wrong.
I don’t need a company judging me and telling me when I’m “ready for the next level”
My career is mine.
A "career path" is an entirely hierarchical notion. You're moving "up" the hierarchy. In a network, you people based on their contribution. The Peter Principle applies only in a career path, not a network. 1/2
We don’t want to define “done.” In an ongoing system, a symmathesy, there is no “done” except death.
Instead, define “better.” Then you can know you accomplished something.
“Best tool for the job” no.
Choose the best tool for the *situation*
which includes who is going to build it, where it is going to run, what it’s going to interact with, what lets us change it, and much more
A ten-principle checklist for socio-technical design
by Albert Cherns, quoted by Jackson in Critical Systems Thinking
paraphrased by me, with commentary for software teams 🧵
Iterative development doesn’t mean you don’t carefully model the software.
It means you use the code and the running software to help you construct that model.
Learning to code, you get good at solving puzzles.
You think, I’ll get a job and solve harder puzzles!
No. Software work doesn’t give you puzzles. You have to formulate the puzzles and then try to solve them, only to discover they aren’t well formulated
“The Controllers belong in the ‘controllers’ directory.
The Views belong in the ‘views’ directory.”
Oh, do you name all your variables “integer” or “string”?
Use the directory structure to communicate some relations between parts in the program!
OH:
If you hire emotionally intelligent people and then shit on them,
Eventually they will quit.
They will quit en masse and leave you in the lurch.
#rubyconf
“Deliver features quickly” is a poor objective for guiding decisions. Delivering this feature quickly is in opposition to the future.
“Deliver features smoothly” aligns means and ends. It requires delivering features, while putting focus on the system.
I find auditory processing expensive, noises distracting.
In calls, one person with background noise or an echo
and I’m struggling to parse the meeting.
Anyone else?
Bad sound quality is cognitively expensive.
JavaScript is the most human language I’ve met. It’s full of history. It tries to be accommodating, but over the years it’s built up defenses. It has many faces for many contexts. It doesn’t have a real module system but it’s working on it.
“Doctors don’t heal. They create the conditions for healing to occur.”
Managers of software teams don’t develop. They create the conditions for development to occur.
Today's reminder.
The browser treats localhost:8080 and localhost:8666 as the same domain.
They will share cookies. Boo!
catdiary.localhost:8080 and ratfish.localhost.8666 are different domains
and resolve just fine on my Windows box. Also great for autocomplete.
My productivity as a senior dev relies on all the steps I skip or do poorly, choosing which corners are cuttable until we know this code is useful.
I’d be super slow if my code were subject to the same scrutiny as a first-year dev.
Good code is
Predictable, Readable, Simple, and Flexible (in that order)
_to the team that works with it_.
There is no absolute standard; good code is suited to its environment, to its people.
@joesmorgan
#ThatConference
"In a healthy piece of code, entropic decay is staved off by dozens of tiny interventions — bug fixes, test fixes, small refactors, migrating off a deprecated API".
Excellent article:
Some of that work can be automated, making it more likely to get done
The stuff I leave on the counter is there for a reason.
The stuff other people leave on the counter is messy and they should pick it up.
Similarly in code.
Competitive culture is oppressive.
It guarantees most of us will be unhappy most of the time. And blame ourselves.
It prevents working together, because then how will we win against our peers?
Why would I want to make the computer think like a human?
I have a source of human thinking already. I want the computer to do all the different kinds of thinking that we never had access to before.
A “performance review” is not an evaluation of me as a person. Not of me as a developer.
It can describe the relationship between me and the company, from the perspective of the company and my manager.
To become an expert:
1) learn how to learn about a thing.
2) declare yourself an expert on the thing.
People will bring problems to you. You will become a repository of their experience.
#theroy