Good notes on Adobe’s platform engineering/platform as a product efforts. Moving from Mesos to kubernetes, getting developers to use the platforms, seeding people to scale skills, etc.
Original source: Adobe’s Internal Developer Platform Journey and Lessons
My earliest professional comics work was all roughed out in crappy notebooks on the back table of a late-night burger bar with a Biro, scribbling away at three in the morning while drunks and ravers with nerve damage staggered in and out of the place.
Original source: The Only Good Notebook – WARREN ELLIS LTD
On thought-leadership language: “business-dude lorem ipsum.”
Original source: Business Dudes Need to Stop Talking Like This
Sep 13 – How to Measure Developer Productivity with Metrics and More
Coming up soon I’ll be moderating a panel about developer metrics. We’ll have three actual practitioners, so what I’m looking forward to is how they actually apply and don’t apply the common DevOps-y metrics, how they put them in place, and how they use them to make the human situation better. Register for it and watch for free!
Also, if you miss the actual date, you can watch the replay.
Register: Sep 13 – How to Measure Developer Productivity with Metrics and More
The idea that you should only do the work you’re paid to do, and instead take all that extra work and time to focus on yourself and family. The argument against this (that you should still put in 110%, instead of just 100% or even 80%) is: “It’s part of an overwhelming trend of pro-boss propaganda, trying to frame workers that don’t do free work for their bosses as somehow stealing from the company”
Original source: Quiet quitting is a trend taking over TikTok and possibly your workplace – “pro-boss propaganda”
Much advice around, of course, food. Turning away the airplane food is a good idea. On longer flights, brining some of your own food is probably a good idea – one I haven’t really figured out too well. That said the food in business class is just fine. Getting sleeping pills would be great, but how does one do that?
Original source: Anthony Bourdain How to Travel – Anthony Bourdain on How to Fly
“You are precisely as big as what you love and precisely as small as what you allow to annoy you.”
Original source: Sizing yourself
“At that age, there is a kind of marriage between the logical act and the dramatic act. They consciously uncouple as you get older.”
Original source: The Paris Review – Diary, 1999
For these conversations to be robust, children have to be interested enough to want to pick up the book in the first place. Children’s literature is increasingly diverse and many books now raise these issues, but some of them are hopelessly ruined by good intentions. I don’t find piousness and pedagogy interesting in art, and neither do children. Hergé’s work is deeply flawed, and yet riveting narratively and aesthetically. I have forgotten all the well-intentioned, moralistic children’s literature that I have read, but I haven’t forgotten Hergé.
Also: “Honestly,” she said, “all I remember is when the sympathizer has sex with a squid.”
Original source: “sex with a squid”
You know, the usual list of mind-zingers, but always good to have more.
Original source: 100 Rules — Personal Philosophy
“If something like that was in one of the main storylines, where you’re actually trying to pay attention to figure out what’s happening, I think that would have been distracting. But like, just a guy up in the corner?”
Original source: An Oral History of Tim Curry’s Escape to the One Place Uncorrupted by Capitalism
Product manage your kubernetes stack to make it more useful for your developers. Think of developers as the customers, rather than thinking of your SL* metrics as the customers. Otherwise, you just have a blinking cursor with awesome uptime.
Original source: Gartner Blog Network
Big sales deals require aligning all the different people at the buyer. With IT stuff, there’s always conflicting priorities and desires across different groups. When they don’t align, it drives 6+ months of delay to the sale. Worse, post-sale you’ll have trouble showing value (leading to renewal, buying again, expansion) as those teams battle it out when it comes to using your stuff.
Original source: Gartner Blog Network
Here’s a short write-up of the developer toil survey the Tanzu Labs people use to find ways to improve developer experience. If you like it, be sure to checkout the white paper we published on the topic, which includes a starter set of survey questions.
If you’re doing anything with programming, apps, or the software you build and use to run your organization, check out the sessions we have at VMware Explore 2022, coming up August 29th to September 1st. (It’s the new name for VMworld, same conference, though.)
Browse the content catalog, and register if you’re interested.
Overly ambitious aspirations often fail. Scale back your digital transformation dreams to starts small, learn, grow, repeat.
06 – Big Bang Releases
The sixth reason why changing, how you do software at large organizations usually fails: doing way too much at once, the big bang release.
Oftentimes, when you’re changing, how you do software at a large organization, you wanna have a big successful release. You’ve got a lot to change hundreds, if not thousands of teams, and you’re investing a lot of time and money and attention from a corporate perspective. So what you really wanna do is build up a case that it’s gonna have a huge impact and it’s worth going through all of this risk and change.
So you build a business case that includes transforming nearly everything within at least a couple of years. The problem here is that until you start changing things, you’re not gonna learn what works and doesn’t work in your organization.
It’s not gonna all go according to the books and the fancy conference talks you’ve seen. You’re gonna have to find the people, the processes, the software, what your customers think. Many things are gonna be unique to your organization, the processes, the cultures that are set up.
You need to start small and ramp up as you learn more to more. and That’s gonna be the way that you actually control risk and costs.
Beware of Luxury, Jan Steen. Kunsthistorisches Museum, Vienna.
Don’t have real CI/CD in place? Check out the Tanzu Application Platform.
05 – No CI/CD
14 reasons why your digital transformation strategy probably will go poorly: the fifth reason.
You probably don’t have true continuous integration and continuous deployment in place. What this means is that you’re not only automating the way that you build your software, that you test your software, that you even make the images or the package of the software to be deployed continuous integration.
But that you also don’t have a way of automating getting that software to production, setting up all the configuration needed the infrastructure, the storage, the compute, the networking, all the other middleware. That’s gonna be used setting up all the infrastructure that’s needed to run that software in production and also having the configuration that goes with it.
And even the monitoring and the instrumentation that you’re gonna need. You’ve gotta think about the entire process that it takes from idea to that code running in production and find all the things that are going in the handoffs between there, you’ve got a bunch of boxes and arrows. And what I find is that people optimize those boxes, but they don’t really think about the arrows, the handoffs and how long it takes to get between them.
So the first thing that you should do is look through that flow of things and find out where the wait times are. What’s taking a long time. Good luck!.
The 14 reason out of 14 that getting better at software and large organizations often doesn’t work out. And that is that you can’t actually change the organization. Whenever you’re getting better at software. You’re often moving from a project based way of doing things where people are assigned features and wire frames, and they just do that and deliver it.
And it’s someone else’s responsibility to make sure it’s successful, evolve it and even run it. However, in a more product way of doing software, the way that really good companies do it. That team that builds the software is responsible for it over the lifetime of the software. They actually write the software and observe if it’s solving problems that people have.
If it’s actually meeting the objectives, the business goals, uh, that people have, what this means is that you’re gonna need to change the organization around to reflect that responsibility that they have. Those teams have to be unified across the life of the software, interact with the business side.
Even interact with customers more and observe them and see what they’re doing, which is not usually the organization structure that you find in most it departments and large organizations. So make sure you can change that organization structure around and start planning on how you’re gonna be doing that.
If you’re improving the way you’re doing software in a large organization.
Handy thinking tools, e.g.: “Hanlon’s razor – When people do something bad, always assume negligence and incompetence before malice.” Also, he doesn’t seem to like the book.
Original source: The Great Mental Models: General Thinking Concepts
Coté
You must be logged in to post a comment.