Threads for juanda
-
Continue with a multi-month effort to move a big rails production application from Heroku into EKS.
-
Pair programing is not about productivity. It’s about reducing the bus factor, spreading knowledge across the team and allowing junior developers to increase their skills.
-
My personal experience with a team who did full-time pairing was that, by the time I’d left, I had never in my life been part of a team where I understood less of the code or infrastructure. While I had exposure to large swaths of the system, the opportunity to actually dig in and grok the things was severely hampered by the pairing process. Combined with the cognitive overhead of constant pair switching (we pair switched between 1 and 8 times per day), and to simplify every single thought I had so it could be communicated verbally, there wasn’t the mental bandwidth left to think deeply about things even if I’d been allowed to derail my pair long enough to dig into something I hadn’t yet understood. I could see how people who are satisfied with a superficial understanding of things might be mislead into thinking that pairing reduces the bus factor, but I don’t think it’s actually the quality understanding that you’d want if people really did leave the team.
-
I had never in my life been part of a team where I understood less of the code or infrastructure
I had the same exact experience. Watching other people code is not how I learn.
-
Pair switched 8 times a day??
Madness.
-
-
There are other ways of reducing the bus factor without pair programming. The most obvious way is to let people work on more than one thing (not necessarily simultaneously).
-
There are others, sure - but as a method of spreading knowledge through a small group , 1:1 tutelage is pretty effective.
-
-
This is incorrect. See my comment above.
If we extend the definition of pair programming to mean a situation where two people work together then the discussion will become meaningless as it’s obvious that collaboration is required in many (most?) cases in all industries. What we’re discussing here is a specific programming technique that was first advocated by proponents of Extreme Programming. You can read more on the Extreme Programming website. A few quotes:
- All code to be sent into production is created by two people working together at a single computer. - this implies that pair programming should be the default mode of producing software.
- Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project. - this claim can be quantified (at least partially). OP’s goal is to dispute it on the grounds that if pairing is more productive than non-pairing then it’s performance boost should be > 100%.
- One thing pair programming is not is mentoring. A teacher-stundent relationship feels very different from two people working together as equals even if one has significantly more experience. - it’s not about training juniors or spreading the knowledge. It’s about improving the code.
-
-
I can’t believe that this guy used Dvorak for 5 years and never thought of re-mapping his text editor to a more ergonomic layout. He’s either trolling or doesn’t know how to use vim as he claims.
-
? author here. At work we pair program so we share a vim config. I don’t think Qwerty users would be happy about moving away from HJKL.
-
-
Do the two of you physically share one computer?
Kind of! There’s a pool of common pairing machines that we ssh into and share our screens using
tmux. -
-
-
-
-
What should be mentioned: Dvorak’s superiority in typing speed is mostly a myth. It’s based on some very weak studies and other than that personal testimonies. There’s no proper science behind it.
-
As of 2005, writer Barbara Blackburn was the fastest alphanumerical English language typist in the world, according to The Guinness Book of World Records. Using the Dvorak Simplified Keyboard, she maintained 150 wpm for 50 minutes, and 170 wpm for shorter periods. Her top speed was 212 wpm.
There’s even a Guinness World Record in typing speed…
-
-
juanda
5 years ago
|
link
| on:
How we got 1,500 GitHub stars by mixing time-tested technology with a fresh UI
This has to be on top of the list of vanity metrics.
-
Heroku is fantastic. In a previous startup, we used to be hosted in Heroku but we moved to Rackspace because of the costs. The app ended up being about 10% faster and the hosting costs a little lower, however we rapidly found ourselves in a position where we basically needed a full time devops person. That decision was too premature and it slowed us down.
Right now, I work for another YC startup and we’ve been hosted in Heroku for over 2 years now. The possibility to focus in development instead of devops is truly liberating. Our business isn’t maintaining updated linux boxes, or dealing with firewalls, but building features for our customers.
They say Heroku is too expensive only if you don’t value your own time. Amen to that.
-
we basically needed a full time devops person.
This is exactly it, and why they can charge so much - I very much doubt a Heroku bill for a typical small company would ever grow larger than the annual salary of a decent ops engineer - and if it does, you know full well it’s time to move away! It would however be nice to have a little more comparable competition in the PaaS space. Heroku is simply king at the moment.
-
-
Why is important to have this discussion 18 years later? I just don’t get it. It seems like a waste of time to have this arguments.
I use a bullet journal where I jot down things and take daily notes about work and life. I also have a Dropbox folder with a bunch of Markdown files that I edit in Caret.