Some people really benefit from hearing advice that everyone knows, for the same reason we keep schools open despite every subject in them having been taught before.
In that spirit, here's some quick Things Many People Find Too Obvious To Have Told You Already.
Charge more. Charge more still. Go on.
We don't see most of it every day for the same reason abstractions protect us from having to care about metallurgy while programming.
Serious people in positions of power eat Thanksgiving dinners, too. Guess what they ask at them.
More from Patrick McKenzie
Here's how I'd measure the health of any tech company:
— Jeff Atwood (@codinghorror) October 25, 2018
How long, as measured from the inception of idea to the modified software arriving in the user's hands, does it take to roll out a *1 word copy change* in your primary product?
Hiring efficiency:
How long does it take, measured from initial expression of interest through offer of employment signed, for a typical candidate cold inbounding to the company?
What is the *theoretical minimum* for *any* candidate?
How long does it take, as a developer newly hired at the company:
* To get a fully credentialed machine issued to you
* To get a fully functional development environment on that machine which could push code to production immediately
* To solo ship one material quanta of work
How long does it take, from first idea floated to "It's on the Internet", to create a piece of marketing collateral.
(For bonus points: break down by ambitiousness / form factor.)
How many people have to say yes to do something which is clearly worth doing which costs $5,000 / $15,000 / $250,000 and has never been done before.
If everyone was holding bitcoin on the old x86 in their parents basement, we would be finding a price bottom. The problem is the risk is all pooled at a few brokerages and a network of rotten exchanges with counter party risk that makes AIG circa 2008 look like a good credit.
— Greg Wester (@gwestr) November 25, 2018
The benign product is sovereign programmable money, which is historically a niche interest of folks with a relatively clustered set of beliefs about the state, the literary merit of Snow Crash, and the utility of gold to the modern economy.
This product has narrow appeal and, accordingly, is worth about as much as everything else on a 486 sitting in someone's basement is worth.
The other product is investment scams, which have approximately the best product market fit of anything produced by humans. In no age, in no country, in no city, at no level of sophistication do people consistently say "Actually I would prefer not to get money for nothing."
This product needs the exchanges like they need oxygen, because the value of it is directly tied to having payment rails to move real currency into the ecosystem and some jurisdictional and regulatory legerdemain to stay one step ahead of the banhammer.
On a serious note, it's interesting to observe that you can build a decent business charging $20 - $50 per month for something that any good developer can set up. This is one of those micro-saas sweet spots between "easy for me to build" and "tedious for others to build"
— Jon Yongfook (@yongfook) September 5, 2019
Every year at MicroConf I get surprised-not-surprised by the number of people I meet who are running "Does one thing reasonably well, ranks well for it, pulls down a full-time dev salary" out of a fun side project which obviates a frequent 1~5 engineer-day sprint horizontally.
"Who is the prototypical client here?"
A consulting shop delivering a $X00k engagement for an internal system, a SaaS company doing something custom for a large client or internally facing or deeply non-core to their business, etc.
(I feel like many of these businesses are good answers to the "how would you monetize OSS to make it sustainable?" fashion, since they often wrap a core OSS offering in the assorted infrastructure which makes it easily consumable.)
"But don't the customers get subscription fatigue?"
I think subscription fatigue is far more reported by people who are embarrassed to charge money for software than it is experienced by for-profit businesses, who don't seem to have gotten pay-biweekly-for-services fatigue.
More from Tech
Legacy site *downloads* ~630 KB CSS per theme and writing direction.
6,769 rules
9,252 selectors
16.7k declarations
3,370 unique declarations
44 media queries
36 unique colors
50 unique background colors
46 unique font sizes
39 unique z-indices
https://t.co/qyl4Bt1i5x
PWA *incrementally generates* ~30 KB CSS that handles all themes and writing directions.
735 rules
740 selectors
757 declarations
730 unique declarations
0 media queries
11 unique colors
32 unique background colors
15 unique font sizes
7 unique z-indices
https://t.co/w7oNG5KUkJ
The legacy site's CSS is what happens when hundreds of people directly write CSS over many years. Specificity wars, redundancy, a house of cards that can't be fixed. The result is extremely inefficient and error-prone styling that punishes users and developers.
The PWA's CSS is generated on-demand by a JS framework that manages styles and outputs "atomic CSS". The framework can enforce strict constraints and perform optimisations, which is why the CSS is so much smaller and safer. Style conflicts and unbounded CSS growth are avoided.
There’s nothing in the Agile Manifesto or Principles that states you should never have any idea what you’re trying to build.
You’re allowed to think about a desired outcome from the beginning.
It’s not Big Design Up Front if you do in-depth research to understand the user’s problem.
It’s not BDUF if you spend detailed time learning who needs this thing and why they need it.
It’s not BDUF if you help every team member know what success looks like.
Agile is about reducing risk.
It’s not Agile if you increase risk by starting your sprints with complete ignorance.
It’s not Agile if you don’t research.
Don’t make the mistake of shutting down critical understanding by labeling it Bg Design Up Front.
It would be a mistake to assume this research should only be done by designers and researchers.
Product management and developers also need to be out with the team, conducting the research.
Shared Understanding is the key objective
I\u2019d recommend that the devs participate directly in the research.
— Jared Spool (@jmspool) November 18, 2018
If the devs go into the first sprint with a thorough understanding of the user\u2019s problems, they are far more likely to solve it well.
Big Design Up Front is a thing to avoid.
Defining all the functionality before coding is BDUF.
Drawing every screen and every pixel is BDUF.
Promising functionality (or delivery dates) to customers before development starts is BDUF.
These things shouldn’t happen in Agile.