101–110 of 271 posts
Earlier quoted context omitted.
I miss it every time I review a behemoth PR, or another engineer proposes a giant design change in a PR. Those discussions need to happen earlier
I’ve been asked to review massive PRs that were produced by a pair plenty of times.
Earlier quoted context omitted.
Agreed, as an ex-pivot I really liked PT (relative to Jira et al.) It was clear the VMWare was going to gut the company, and Broadcom only made that clearer. It was once a great company... (Pivotal Labs) Now it's toast.
I have never understood the VMWare/Pivotal thing, to the point where I assumed there must be two different companies named that for VMWare to have bought a company called Pivotal.
Free business idea: clone Pivotal Tracker as a solo dev / small team. People often ask: how do I find business ideas? Well, here you go: many people publicly saying how they love a product that is going away. This is a validated product: people were paying for it. Apparently quite a lot of people. It doesn't get better than this. All you have to do is to clone the product. You can literally market it as a Pivotal Tra…
I think the biggest challenges are that a) the vast majority of solo devs capable of pulling this off quickly are well-employed, and b) the timeline for MVP++ is effectively January 1st, else the migrators will make different decisions.
And that as soon as migrations happen, your storage costs will balloon, so you need a billing strategy on launch.
Free business idea: clone Pivotal Tracker as a solo dev / small team. People often ask: how do I find business ideas? Well, here you go: many people publicly saying how they love a product that is going away. This is a validated product: people were paying for it. Apparently quite a lot of people. It doesn't get better than this. All you have to do is to clone the product. You can literally market it as a Pivotal Tra…
The biggest risk: people are going to flock to Linear, which is the next best thing.
Pivotal Tracker was the first time I saw a digital kanban board where the workflow was represented as a series of columns you dragged items through. Since then, its become popular paradigm for pretty much every popular project management software UI around. I always wondered, did Pivotal Tracker invent this paradigm? They were surely using it before any of the big players utilized it.
At our height, the owner started bringing in more projects than our current workflow could handle. Customers started getting angry because their projects would slip through the cracks and get delayed if they weren't calling us up weekly to nag us for status. I sort of became the project manager by default because I touched most of the projects in some way and I was the go-to guy when someone had a question about the status of a project. I wasn't really happy about this because I liked doing tech stuff more than I liked managing projects.
In an attempt to preserve my sanity and get back to logging billable hours, I grabbed a deck of blank index cards and wrote down the company name, project name, status and for each project we had. (I didn't like spreadsheets at the time and this was faster than writing code.) That way, I didn't have to actively remember the status of every project. When needed or when asked, I could just grab the card and look. Once a week or so, I would update the status of each project on the card.
Not long after, I got to noticing that there was really only four (or five, I don't recall) states that any project could be in and decided to stop writing them on the cards. Instead I placed the cards in dedicated piles that represented the project's status and moved them around as needed. That worked well. Eventually, I thought it would good if everyone on the team could see the projects and their status as well, so I grabbed an old whiteboard, hung it on the wall behind me, drew a column for each status, and taped all the cards into the column corresponding to their status. This was a BIG improvement. I stopped wasting an hour every morning just going over project status with the boss and other employees. Everyone could just walk over to the area near my desk and look at the wall behind me. (It was an open-plan office before those were "cool.") Others could move the cards between columns themselves. When a client called demanding an update, I could just glance behind me.
A few jobs later, I took a compulsory three-day seminar on Agile and saw that they called this thing a Kanban board.
Earlier quoted context omitted.
I had some thoughts on Jira: https://honeypot.net/2021/10/01/jira-is-a.html TL;DR it's so completely customizable that it's more like a DIY project management toolkit. Pivotal and Linear have/had a more opinionated approach: "here's how you manage projects. Good luck and have fun!" Jira almost seems to push otherwise rational people to build the most baroque processes imaginable.
> Jira almost seems to push otherwise rational people to build the most baroque processes imaginable. PM's gotta justify their jobs somehow.
It's just that I've never worked with someone I considered a good PM who loved Jira. The great ones wouldn't care if we did all the planning on papyrus because they were more concerned with getting things done than documenting them in excruciating detail.
Free business idea: clone Pivotal Tracker as a solo dev / small team. People often ask: how do I find business ideas? Well, here you go: many people publicly saying how they love a product that is going away. This is a validated product: people were paying for it. Apparently quite a lot of people. It doesn't get better than this. All you have to do is to clone the product. You can literally market it as a Pivotal Tra…
Ah, I do love the smell of fresh optimism in the morning! I think the biggest challenges are that a) the vast majority of solo devs capable of pulling this off quickly are well-employed, and b) the timeline for MVP++ is effectively January 1st, else the migrators will make different decisions. And that as soon as migrations happen, your storage costs will balloon, so you need a billing strategy on launch.
Unless people somehow figure out a way of hosting stuff somewhere else than Amazon/$host_that_charges_per_mb_transit (Hint: they exist)
Considering it would have to be a lean operation (assuming bootstrapped), then figuring out basic stuff like "We don't want to pay per MB sent" should be a pretty high requirement.
The thing that I always liked about Pivotal is that it was visibly obvious that there was only one queue. It forced everyone to ruthlessly prioritize and make the hard decisions. In this moment, do you want me working on this bug, or this new feature? You have to decide - you get one or the other. It avoided the "Everything is a high priority" dilemma.
https://longform.asmartbear.com/jit-backlogs/
Each client manages their queue order, so the dev team just needs to focus on the head of each queue. (Of course, the dev team should also work with clients to clarify the requirements for the next few tasks in their queues so the head task will be shovel-ready). The dev team can then choose which queue heads to prioritize and maintain a balance, such as always have one tech debt task and X bug fix tasks in progress in addition to client work.
Earlier quoted context omitted.
Ah, I do love the smell of fresh optimism in the morning! I think the biggest challenges are that a) the vast majority of solo devs capable of pulling this off quickly are well-employed, and b) the timeline for MVP++ is effectively January 1st, else the migrators will make different decisions. And that as soon as migrations happen, your storage costs will balloon, so you need a billing strategy on launch.
> And that as soon as migrations happen, your storage costs will balloon, so you need a billing strategy on launch. Unless people somehow figure out a way of hosting stuff somewhere else than Amazon/$host_that_charges_per_mb_transit (Hint: they exist) Considering it would have to be a lean operation (assuming bootstrapped), then figuring out basic stuff like "We don't want to pay per MB sent" should be a pretty high…
Earlier quoted context omitted.
Ah, I do love the smell of fresh optimism in the morning! I think the biggest challenges are that a) the vast majority of solo devs capable of pulling this off quickly are well-employed, and b) the timeline for MVP++ is effectively January 1st, else the migrators will make different decisions. And that as soon as migrations happen, your storage costs will balloon, so you need a billing strategy on launch.
> And that as soon as migrations happen, your storage costs will balloon, so you need a billing strategy on launch. Unless people somehow figure out a way of hosting stuff somewhere else than Amazon/$host_that_charges_per_mb_transit (Hint: they exist) Considering it would have to be a lean operation (assuming bootstrapped), then figuring out basic stuff like "We don't want to pay per MB sent" should be a pretty high…