Friday LeanCoffee Notes
Matt Heusser
Should we focus on a particular tool, technology today or the tools of the future?
The tools of the past can be updated continually
The tools of the future may be better
Emma: With respect to tools do you mean tools like angular or frameworks?
I was thinking of frameworks but I wouldn’t exclude the specific tools.
Emma: Angular 2.0 might not be backwards compatible with Angular 1.x. Ember doesn’t have the same community and might not have the stronger future. Updating a dependency can be it’s own little project that slows down the velocity — or someone does it as a sideline task and doesn’t tell you, there is new testing work that is hidden.
Matt: Keeping a framework or tool up to date introduces drag, not doing it introduces other risks.
Matt: Microfocus is still selling cobol.
I generally agree with you, but I know people in large corps that specialize. I know 3 that are cobol programmers.
Seb: If you go into a new tool that can be just as obscure as the old tool. If you learn a new tool and no community forms around it you can be just as irreplaceable as the old tool.
Emma: When that happens it can be hard to hire as well. “We want you to come work on MVC 1.0”
That’s a really good point. When we are looking to hire people where I am now — if we wanted people to come to MVC 1.0 or web forms development, it makes it harder to hire.
Matt: Personally it’s hard for me to get excited about “I am an X developer.”
Emma: I think the safety part of me wants to go for established tools.
From a development perspective when people chase new and shiny that can be distracting.
Emma: It’s really difficult to integrate new tools, especially tools that require buy-in frome everyone that people can avoid - like communication like IM.
Seb: The fundmental way we do things hasn’t really changed in the past 50 years. If you don’t try something new once in awhile, how do you ever introduce new things?
Matt: Innovation sprints and hackathons are two ways to plan to bring in the crazy new ideas without disrupting flow.
Do you have any specific educational initiatives?
Emma (host): We’re doing Katas, Mentors, Brown Bag Lunches
We have a weekly lunch and learn which is most frequently finding a video online, monthly we have a longer session where we get food.
Pillar does a monthly retrospective that brings all the consultants into one building, company update, bring in lunch, talk about new initiatives, refresh relationships, etc. That’s more learning about the company than learning technology.
Emma - the other day I heard “You know in notepad if you press F5 you get a datetimestamp” - if no one tells you, you don’t know.
Camtasia is a commercial product - if you see a behavior you need corrected, just make a video explaining it. Then the new hire can learn it.
Learning library of video.
Sebastian: I’m a developer. As far as learning initiatives go, we have broad initiatives - training videos, conferences. My coworkers and I have approached people about doing things during lunch. Some colleagues and I made a alternative viewer for the conference schedule using the code mash API.
It’s in javascript
Emma: We recently tried to use mob programming as an educational initiative. I understand the merits of it but it turned into loads of people typing at a keyboard.
How Do You Manage Multiple Technology Stacks
Matt: I don’t see a problem. One stack per team, communicate by a REST API or some other standard interface.
Emma: Is there not a danger of people becoming diluted in their knowledge as you get more stacks.
You say one stack per team, but does that mean you support your own stuff?
Matt: My preference is yes. Architecture sets up a VM for production and the development teams supports and maintains it.
I’m testing multiple stacks, and I’m configuring systems and mocks and things on multiple client tools, and my knowledge can get so thin that I don’t really know what is going on. Plus now you’re writing C# to drive selenium and javascript - it gets difficult even if just have “one stack for a team.”
Matt: I really like pairing for knowledge sharing. Why is it such a hard cultural sell?
Emma: I think some of it is fear of failure.
Rob: I think some if it is developers don’t know how to communicate well.
Emaa: There’s one constant problem, that’s the people.
Historically, the demographic of developers was pretty narrow, and part of the legend was linus torvalds writing linux in his basement. So people get jobs and wonder “hey, why are the lights on and why do I have to talk to people?”
Rob: So we worked for ~18 months, sitting in a room together at an outsourcing company. The client wants us on-site for three weeks at go-live. So we move to the client which has cubicles in a physical wall, just high enough that we can’t see the other person. So my friend who I worked with for 18 months is three feet away, but we can’t see each other because of the cube walls. So he IM’s me. I stand up and ask “what are you doing? I’m right here.”
Emma: Sometimes people don’t ask because “you look busy”
I think with pair programming the whole storming norming performing kicks in - you have to figure out is it okay to ask questions? Am I giving off signs that I don’t know what I’m talking about? You get to the point where it is okay to not know.
Emma: Arloo Belshee has an article that is a language of pair programming; the phrases he uses to mean “I’m not sure” so people know what to say and know what they are hearing.
Reading the Classic Literature
I’ve been having fun reading the foundation literature from the 60’s, 70’s, and 80’s. For example, a lot of Dijkstra’s writing from the early 70’s - about proofs - suggested you develop the proof right before the code.
What should we be reading and how do we have that longer memory?
Matt: I’m a big fan of Jerry Weinberg; his quality software management books still hold up.
Rob: His Technical Leadership book and psycology of computer programming books are really good
Matt: I’ve never read Donald knuth’s art of computer programming, but I’m interested.
Rob: It’s very intense programming. I’m not sure how relevant it is today.
Emma: Someone mentioned Charles Pertzold’s Code
Sebastian: Javascript the good parts.
Fred Brooks Mythical Man Month
Matt: Software Craftsmanship the new imperative
Rob: Yourdon’s Decline and Fall of the American Programmer
Rob: I read Alan’s Cooper’s About Face in 1992 on UI principles
Matt: The Deadline by DeMarco is a novel
PeopleWare by DeMarco/Lister
Main takeaways from the conference
Matt: I enjoyed the docker and hadoop, and I was reminded of the problems of installing and configuring these open source projects - everyone has them.
Rob: I liked the reminder of the classic stuff. A long time ago I picked up Steve McConnel’s Code Complete, 1st edition, and went through the references.
Derek: I liked the reminder of the abstractions on top of the hardware platform.
Emma: Things continue to get more complex. Apple just changed from screen width consistency to screen ratio. I remember being upset a few years ago being upset that there were so 3 redhat, 3 solaris, and 3 windows version to support. And now there is so much.
Sebastian: I really enjoy the rust precompiler; it’s what I initial training . I honestly think so far the lean coffee has been the most valuable part of the conference.
Jason: There were all sorts of things I learned but I’m not sure I have a takeaway.
There were all sorts of technology stuff I learned but I’m not sure I have a theme,