Sharing a post here https://medium.com/hackernoon/feels-like-faster-vs-makes-us-faster-828686facc7e

This blog post reminded me to write down my argument against using heavy process to do planning. “The Case for ‘Developer Experience‘” or full link https://future.a16z.com/the-case-for-developer-experience/?
This particular quote is my inspiratioin
So if I were to coin a law, it would be this: Any system of sufficient size and maturity will always involve multiple languages and runtimes. Software is heterogeneous, and until we as a community accept this fact, we’re upper-bounding how far we can get with developer experience. I call this The Software Heterogeneity Problem, and it has significant consequences for software development, management, and performance.
I’ve argued that building software is much more of an Art than Science. The teams who follow the agile manifesto strictly over plan this artistic endevor of birthing software from nothing with T-shirt sizing, rule of thumb and or fibonacci numbers in 2 week increments of a sprint. What I’ve observed in the real world of software engineering in 20 years is that during the planning and estimation process:
My recommendation for high performing software engineering teams is to try:
Some disclaimer and background here
What portion of your team’s time is spent planning vs. designing and writing and testing software?
Even when you did a great job in planning, how often is your plan exactly on target?
When you hit the target of what you plan after 3 months, is that plan still the right thing to solve?
My team recently had an idea for a metasearch engine. We had a vision document, explored different options to solve the problem, and then did a 2-day hackathon. With zoom audio, 4 engineers, and 43 pull requests later, we have a working prototype that answered these questions.
Our hackathon’s team outcome was that we learned to work with each other much better, intensely with 43 pull requests. The 4 people have a better sense of ownership and understanding of the technical and product vision. The team is much more excited to move forward with the next steps.
What we need to solve?
As software engineers, our job is to create useful services for other humans or other services that depend on our services.
In the idealized world, we write software, deploy, and move on.
In the real world, we have to think about
This is the world of a software engineer beyond just writing code. As an engineer writes more code, they have more ‘legacy’ to support. For an engineer to be effective, what they create needs to be continually groomed and tend to. How they enable others to help is an important factor to help them scale. How they enable their future self to look at code they had written 1-2 years ago can be done through rigorous automated testing and up to date document and knowledge sharing.
As a developer, why test manually when you can have the machine do it for you for UI testing?
Check out Saucelabs.com and Sauce Connect here
At work when I am interviewing for candidates to join my team for Engineering Productivity, I look for certain attributes.
Having an opinion based on authority and experience
I am looking for someone with one or two areas of deep expertise. Also you should have a strong opinion but here is the kicker, you need to be willing to listen to another opinion. Diversity of opinion, recognizing that there is another perspective and be willing to listen.
Be able to talk about a topic and deep dive.
When answering a question, I will continue to push you to explain or expand deeper. I want to discover how deep you know a subject matter.
Know how to communicate which means listening
I will let you talk and respond for as long as you want, in the meantime I am looking for how long you talk non stop before checking in and see if you have answered my questions. Part of communication is listening.
Splunk is a company of thousands of talented individuals, distributed across product development offices in 8 offices in the U.S., AUNZ, Europe, and Asia.
How do we do our best work collectively and continue to push innovation while expanding at hypergrowth rate? How do we overcome the boundaries of timezone, physical location, and organization rigidity in order to create the most innovative products and solutions for our customers?
After working on Engineering Productivity at Splunk for the last 3 years, I struggled to understand WHY I chose which projects I devote time and attention to. There was a common thread, there was something there to the madness.
The list of seemly random efforts all have some type of common theme that my beloved wife, Katherine point out this weekend when I ask her for her always piercingly accurate perspective.
Here is the laundry list of random efforts:
In my next post, I will try to talk about the common themes I have identified
Photo: Calder & Picasso exhibition in Paris 2019
Amazon popularized the silent meeting
Give this a read on medium.com
“Silent Meetings” are meetings where most of the time is spent thinking and discussing the topics at hand. Functionally, they are based around a “Table Read” that everyone at the meeting reads silently, comments in and then discusses. An assigned facilitator leads the comment synthesis and discussion to ensure the meeting is valuable.
6 offices in San Francisco, Santana Row, Vancouver, Seattle, United Kingdom, Boulder and Sydney are received 145 copies of 3 books.
Pragmatic Programmer, The Code Complete & 97 Things Every Architect Should Know.
Happy reading fellow engineers!
(The photo is one of my favorite pencils I borrow from my daughter. I finally used up all the lead in the pencil)
20 minutes, that’s all it takes. “Could you show me how you work?” Let’s turn on screen capture. Oh, interesting, what else? Why do you like this over, let’s say this other thing X?
Oh, that’s interesting you do it this X way. I always thought people doing it the Y way.
(This post is not for you, it’s for me)
It started out as 5% of my time. Just a 4-hour hands-on workshop with new hires once a month. Now it’s the following