Is Extreme Programming a closed source commercial software development methodology? What makes it so?
I went through a period of my career where I dived head long into it, read Kent Beck's book, liked what I read. Tried pair programming, TDD etc, loved it. Found team that felt the same and had a great couple of years.
Given the book, the many conference talks etc and comparing it to other flavours
of agile that went full corporate (Scrum, SAFE). I'm surprised to hear it described as closed source.
I'm sorry to hear about your neuropathy, I'm glad my suggestion eases your mind!
On pairing in general: For a long period of time when I worked at bigger companies (before co-founding my current venture) I pair programmed 90% about of the time.
For the most part I really enjoyed it, we alternated pairs quite frequently and I worked with people at a range of seniorities. I really enjoyed alternating between playing the role of teacher vs learning from someone much better at the (insert programming language, database, business domain).
I think during that time I also had some of the most stimulating and deep conversations about software development. When pairing, pairs have a deep shared context that's hard to replicate in other scenarios.
There are some drawbacks though, the main one being it's extremely full on and emotionally tiring. I'd class myself as a high functioning introvert and after a day of pairing I needed some serious regenerative quiet time!
My advice to someone considering this suggestion would be to try some pairing now with friends or colleagues and get a feel for it and see if it works for your personality and working style.
I don't know why, but I've often thought about the situation the Josh finds himself in. IE - having to find a different way of building software if I couldn't use a keyboard and mouse due to medical condition.
The solution I always imagine is paying someone or having my employer pay someone to strong style pair program with me. Perhaps a student, junior developer or even someone unfamiliar with software development entirely.
For those unfamiliar with strong style, this rule sums it up: "For an idea to go from your head into the computer it MUST go through someone else's hands". Like the standard driver / navigator pair programming technique but with the navigator never touching the keyboard.
In the case of someone completely unfamiliar with software development I imagine that there would initially be a dramatic high / low skill gradient between us, with the person essentially transcribing. However given the intensity of the practise I think this gradient would level out quite quickly.
At my fully remote startup we operate a variation of this that I think can feel less onerous than a culture of verbose written communication.
- We create living documents / whiteboards on Miro (formally Realtime Board) that relate to the features we're working on. Things like pictures, architecture diagrams, draft db schemas. All at WIP stage.
- When we need to create communications (like requests for comment, demos etc) we record a short video using Loom. The video usually centres round some area of the whiteboard or in the IDE.
- We post this both on a notion page and in slack (using a public channel as to article suggests), tagging those that need to know or would find interesting. Keeping a long list of previous videos in notion helps find useful data later.
I think the low barrier to entry for recording video over the top of documentation thats "just good enough" to get the idea across has lead to universal uptake across our team. It's also easy to slot in reviewing these videos and responding during natural breaks in flow.
For more critical areas of the code / operations we document more formally towards the end of a feature development cycle.
Stay Nimble | Full Stack Engineer | Anywhere +/-3 GMT | Full Time | Remote
Stay Nimble is a fast-growing, social enterprise start-up building a unique digital career coaching platform to support millions through career change and to find their purpose in the new world of work. The platform guides people through a journey profiling their strengths, using machine-learning algorithms to suggest well-matched career options and directing them to access best-in-class learning and career coaching resources tailored for their needs.
A business fiction book that describes "The Theory of Constraints" a process initially applied in manufacturing that deals with optimizing production line systems.
I found the sections on identifying a bottle neck in a system, focusing on optimizing the system around this point and re-evaluating system performance afterwards very applicable to software engineering.
Everything from CICD pipelines, the flow of work through your team to or performance optimizing a service oriented architecture.
Very much a fore father to books like Phoenix Project mentioned by others here.
I recently read Carl Newport's "deep work". One of the points he made that struck home the most was that a leading indicator of success for most knowledge workers was the number of hours spent doing deep work. Ie - the number of hours spent doing uninterrupted work that makes use of your differentiated skills.
As a remote worker the thing I treasure most is the opportunity to organise my schedule to spend the majority of my time doing deep work. Frequently communicating and getting feedback on my work asychronously rather than constantly being interrupted and dragged into synchronous interactions as in an open plan office.
The thought of allowing anyone to contact me at any time, at the push of a button feels like a huge step back.
There are lots of challenges around communication in a remote company, however I don't think the solution is recreating an open office online.
A lot has already been said in the thread about identifying, aligning with and assisting in achieving your organisations goals. I'd also add part of "speaking like a leader" is speaking in a persuasive manner, convincing other in helping with the above.
I found "Thank You For Arguing" by Jay Heinrichs a really good introduction to this.
I went through a period of my career where I dived head long into it, read Kent Beck's book, liked what I read. Tried pair programming, TDD etc, loved it. Found team that felt the same and had a great couple of years.
Given the book, the many conference talks etc and comparing it to other flavours of agile that went full corporate (Scrum, SAFE). I'm surprised to hear it described as closed source.