Sidu Ponnappa

Sidu Ponnappa



For every like on this tweet I will reply with something that most folks in tech and tech-adjacent industries don't want to hear. Hit me.

We're extremely bad at estimation, and routinely overcommit and undeliver. This cannot be fixed, only worked around.

Making execution commitments based on objective numbers doesn't work. This is doubly true when we don't know those numbers up front. (Thanks the gods I didn't say by when I'd deliver on my commitment in the OP)

Estimates in days/dates have the highest margins of error, usually in the hundreds of % range.

The only reliable way to make execution faster and estimation more accurate isn't to add people to the project, it's to remove them.

If you are building a team to build a product you now have two problems and the first is the harder one.

If you are building a recruiting team to build a product team to build a product you now have three problems and the first is the hardest one.

It is easier to raise money than it is to find PMF

Nobody can learn to code in 12 weeks

Most folks who get into this game for the money end up hating the work

Running a profitable cafe/restaurant/bar is harder than being salaried in tech. Much harder. Much much harder.

Most folks who get into this game for the craft end up hating their jobs

A startup that doesn't need to be profitable will almost always crush a competitor who does

You are not Steve Jobs

The smallest team has 2 people

Teamwork is not the norm in tech. Most 'teams' are a bunch of solo players working really hard to minimize their touch-points. Remote work accelerates and incentivises this behavior.

Speaking of teamwork...

Also, if you are nodding while reading this, when you become the CEO you will do the same thing but will rationalize it because you "understand developer productivity".

Attachment to the things we build is an incredibly real problem.

Practice throwing away the things you build.

ngmi won

court order > smart contract

most types of financial transactions are useful only when they aren't anonymous

for most problem statements, using the blockchain dramatically decreases the probability of finding PMF

most DAOs don't work out because there are people involved

remote execution is slower and more error prone

open source teams have been remote first for ~30 years now

most mainstream open source teams casually outperform the execution throughput of most in-person startups with comparable headcount

in-person companies that have not historically outperformed comparable open source teams in their execution throughput are unlikely (polite understatement) to do so when they go remote

remote first is the future

The modern internet based global economy was not created by capitalism. It is almost entirely built on foundations laid by unpaid volunteers contributing to open source because doing so made them feel good.

Remote first knowledge work renders almost all existing management theory obsolete.

a remote-first company that co-ordinates execution in real time using sync chat is unscalable

a remote-first company that co-ordinates execution in real time using meetings is absolutely 100% unscalable

the only currently available body of management theory for remote first work is in open source open source management policy and practice is ridiculously detailed and rigorously enforced at a level most companies can't even dream of

if your remote first company doesn't have strictly enforced topics for chat channels and mailing lists - which means violaters are warned, then kicked, then temp banned, then perm banned - your communication will not scale. no, managers and 'non tech' don't get a free pass.

open source teams reject contributions that don't meet their standards, both hard (i.e objective and usually automate-able) and soft (i.e core team review) for-profit companies have incentives that work against this discipline

open source teams give one another frequent, detailed and open feedback on top of contributions. while the tone and content has been problematic on some oss teams, the practice remains essential to remote collaboration. for-profit teams almost never do this. 2x true in mgmt.

in most remote teams, managers are the weak link when it comes to the execution discipline that is essential to delivery

devs on open source teams talk to their customers all the time and personally handle customer support devs in most remote teams prefer to not talk to their customers and avoid personally handling customer support; this is exacerbated by managers who favour 'clarity of roles'

open source teams don't have to deal with cross border payroll, esops and HR compliance remote first teams do, and oh boy it is hard and expensive

the idea that a remote first strategy allows exploitation of local compensation standards to get cheaper talent is unscalable; you will eventually have to pay everyone the same turns out people tell each other their salaries even though they're contract tells them not to

remote first teams scale on the quality of their written artifacts bad writing means bad scaling

remote first managers manage in writing

if you can't write, don't go remote

proof that quality software matters to a company is that the best, most expensive talent they can afford owns quality assurance

js lacks taste

frontend is easier than backend only when solving easy problems

there is no easy way to become a good programmer

disdain for project management is strongly correlated with incompetence

most interviewers who index heavily on DSA questions in interviews have never applied DSA in prod, and never will

most folks in tech fail when solving problems with solutions in (fairly) standard textbooks. some of these are > 30 years old.

it's wildly improbable that you can learn what's in a textbook from a combination of videos, podcasts and blogposts.

startups are for-profit companies

you probably don't need AI

a model that isn't used is useless

those with little experience struggle to come up with viable startup ideas because they don't know enough those with a lot of experience struggle to come up with viable startup ideas because they know too much

1 in 1000 startups succeed yet we all believe that ours is the 1

capital beats craft in most cases

life usually gets much harder once you're CEO

you don't usually get richer once you're CEO

you can tell a lot about an industry by examining it's tools, and we use jira

asana is better than jira... for todo lists

scrum is not a good default

in most companies, performance reviews are the greatest contributor to undesired attrition

when the programmers are competent, most defects originate in requirements

turns out a 1 sentence ask over chat is easier than writing an RFC, who knew

the most broken thing in our industry operationally is requirements

most who talk trash about OKRs have never set goals for teams (yes OKRs are a shitty tool, that isn't my point here)

The entropy of complex systems only increases. Code, orgs, processes, policy, budgets - they all only get worse as they are modified, even if they were elegant and clear to begin with.

Our titles are all largely useless when it comes to communicating capability and skillset because every tech company is a snowflake in how they build products. No two VPs of Eng are the same No two PMs are the same No two SDE2s are the same etc. etc. It's pure status.

Commissioning a product is a first-class skill that isn't taught anywhere, yet. The state of the art in the industry is at Alladin levels - you roll up, rub the lamp three times and make a wish. Unfortunately, there's no genie there, just a hapless PM.

All product companies are internally structured as a captive software services org + a distribution org Of course, most are in denial of this ("ew, services") even though it's obvious once you draw the org structure.

We don't know how our products get built, when you get down to it. If car manufacturers ran their r&d + factories like we run product development, driving would be the most dangerous activity in the world.

The state-of-the-art solution in mainstream management theory for scaling a tech company rn is "hire more people". (yes, there are textbooks for this. no, nobody reads them - almost zero of execs and product managers I've interviewed over the years had even heard of them)

Most of us don't track defects. At best, we track bugs, and usually not even those.

If you use branches, you don't trust your contributors. In open source, this is logical. In a startup, it means your hiring is broken.

You can either do branches or continuous integration, never both at the same time.

Processes are code that run on people. They're as much a part of your product as the code is.

You can either be courageous or be safe.

"Improving the product" as a personal goal is negatively correlated with job security.

If you aren't closely involved in distributing the product, you can't claim with any certainty to know how to improve it.

Features are a marketing and sales abstraction. You can sell features, never build features. If you're building features, you're using the wrong abstraction to encapsulate product requirements.

If you expect your contributions to be recognized on their merits, you don't understand how performance reviews work... or how humans judge one-another, for that matter.

We say that we prize talented, kind malcontents but our performance reviews say otherwise.

Programmers must needs be reminded to see the art at the heart of their work. Designers must needs be reminded to see the science at the heart of their work. (h/t @abhinitial)

Done right, there is meaning to be found in what we do. This is true of any act of creation.

It is improbable that anything we are working on will change the world.

Disdain for HR surfaces one of the greatest blind spots in makers.

If our hiring, execution and perf review processes could be relied on, we wouldn't need to create branches.

If nobody is getting fired over your standards, either you have the perfect team, or you have imperfect standards.

It is perfectly feasible to have every line of code reviewed as it is written, every commit merged as it is made. I've done it for years. This is what continuous integration is. Everything else is just integration.

computer science is about how computers work software engineering is about how people work with computers, most especially how people work *with each other* while working with computers

at any non-trivial scale, for-profit consumer products manipulate their users' behaviours in ways that are detrimental to the users; this holds even if the makers of the products work really hard to do the right thing

you probably don't need that exotic architecture most vanilla oss stacks are going to out-of-the-box handle scales most startups will never hit, ever

most 'idea people' in companies are 'too busy' to spend an hour writing up a one-pager explaining their idea, but expect hundreds or thousands of maker hours devoted to building it anyway because 'look I just explained it to you in this meeting, it's a good idea, right?'

experienced engineers worry about budgets and have friends in the finance team

in tech, the probability of losing one's job to AI is strongly negatively correlated to the effort one puts into honing one's craft

I would be less worried about our collective moral compass if we spent as much time building a consensus on AI rights as we do talking about AI's impact on jobs

Ask a stratbro for a deck, and you feed him for a day. Teach a stratbro to own a metric, and you feed him for a lifetime.

Follow us on Twitter

to be informed of the latest developments and updates!

You can easily use to @tivitikothread bot for create more readable thread!
Donate 💲

You can keep this app free of charge by supporting 😊

for server charges...