It's a well kept secret that most programmers would program even if we didn't get paid for it. (Shhhh!). I think because of that, we sometimes lose track of the fact that we work for businesses, and that businesses in turn work for their customers. 1/4
That's where the money with which they pay us to have fun ultimately comes from—customers. If we don't make the people with the money happy (that is, the customers), the business will cease to exist (and no more fun for us). 2/4
So, it's our primary job to make those customers happy by providing something that THEY find valuable. Not "internal stakeholders." Not "business people." Not some Product Mgr that calls themselves a "customer." Actual customers. The ones with the money. 3/4
I think we would all be well served if we didn't forget that. Ultimately, we all work for the customers, so they have the loudest say in what we're building. 4/4
(And yes, the VC system perverts all of that because, suddenly, the "investors" are the ones with the money, not the customers. The VCs can drive the company in ways that destroy long-term viability, when they're no longer around. That's a good reason to not take VC money.)

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Allen Holub

Allen Holub Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @allenholub

15 Oct
The idea of "sales" is hard in an Agile world where the thing you're selling is changing all the time. The sales people, however, can work to increase sales by identifying places where the user community (not one "prospect," but the general community) needs improvement. 1/5
In other words, the sales folks are alies who are effectively collecting potential user stories for us. For that to work, however, you can't have them screaming for some feature just because a single client wants it. That behavior is amplified by a commission model. 2/5
It's actually money in their pockets if they can get you to make a single client happy. We need to change that to a model the rewards making the community as a whole happier, not single customers. 3/5
Read 5 tweets
11 Oct
I was a double CS and Medieval-History major. One of my banes in the latter was learning Latin. The problem was that Latin was taught as a "dead language." (The prof in my giant Latin class made that very explicit in the first lecture.) 1/4
We were subjected to long boring lectures, then had to go off on our own and memorize/study. That's no way to learn anything. Learning comes from doing. Had we actually spoken Latin to each other *in class,* things would have been way easier. 2/4
All this applies to programming as well. Too often, we think we should learn on our own and then somehow apply that info effectively. We don't start really learning until we apply what we read, however. 3/4
Read 4 tweets
11 Oct
"Working software is the primary measure of progress" is an enabling constraint. Sometimes, managers use the phrase as a club to get people coding. Coding, however, is a necessary driver of creating software, but it's not the only thing you have to do. 1/5
Standing in front of a whiteboard and discussing design, creating and running tests, just staring out the window and thinking, are all necessary parts of the development process; but if you don't get that software into your customers hands, you've accomplished nothing. 2/5
Using working software (the result of the process) as your measure of progress, puts natural limits on the entire process, including the staring-out-the-window parts. It forces you to work small (thus the "constraint") enough to deliver frequently. 3/5
Read 6 tweets
24 Sep
How do you split work into Initiatives and Epics, as required by Jira? Don't split it like that. The basic unit is the product. You move the product forward by capturing stories of the user's work, then modify the product to support that work. 1/4
"Intiatives" and "Epics" were made up by Atlassian. They do not, and never have, have any part in Agile thinking, and have nothing at all to do with story-based planning. 2/4
Stories desribe your user's work. They might be so nebulous that they're not ready to put onto your backlog, but those "Epics" have no place in anything except strategic planning. An "Epic" is not a bag of stories. It's a story so nebulous that you can't implement it. 3/4
Read 4 tweets
22 Sep
I really don't understand the hate directed at Design Patterns (both the book and the practice). Design patterns are DISCOVERED, not invented. Gamma et al just cataloged patterns that they disovered by reading lots of code written by people who didn't know one another. 1/
They didn't invent those patterns. They just said: we looked at a lot of well-written code, and when we focused on certain problems, patterns started to emerge in the solutions. 2.
Criticising the GoF is really criticising the code of many hundreds of talented programmers working independently. Sure, the patterns aren't appropriate everywhere, and it's often best to start simple & refactor into a pattern, but they say that pretty clearly in the book. 3/3
Read 4 tweets
21 Sep
This diagram has gottem me thinking about management structure. We all (at least /we/ all) agree that cross functional teams is best for development. However, that cross-functional, colaborative structure disappears up the organization, where VPs, etc., are not a team at all. 1/
So we have a situation where there's a collaborative executive team, collaborative execution teams, and everybody in the middle are separate individuals, often working at odds. I don't really see how that can work. In fact it doesn't work very well. 2/
We have a tension betwen any hierarchical structure, which is about giving orders and single people in control, and collaborative cross-functional teams. The only soln that makes sense to me is to go to collaborative cross-functional teams everywhere, even at mgmt levels. 3/
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!