The new dashboard experience, previously available as a feature preview, is now the default view for everyone. The redesigned dashboard helps you focus on the work that matters most and…
46 comments
This seems to push your issues and pull requests as the main items of the page, and that's significantly better.
Central Question: What pragmatic work tracking advice do people have for tiny (1-4; 1 founder, 1-3 contractors) team sizes, analog or digital?
Context: I noticed a source of friction for my larger solo projects (1+ months) was a lack of structure and carrying the entire project in my head. Effective for hackathons but life is starting to force me into more context switching (getting older I guess). I've already refactored my work system to involve an analog weekly planner + weekly retro/plan ritual, heavier emphasis on digital calendar, adopting a two phase work philosophy (planning/grooming, task execution) often facilitated by pomodoro (5 minutes plan, 25 execute), and leaning on having a digital work tracking system.
I've taken a large bet on GitHub's ecosystem. Issues + "type:" labels let me create ticket types (spike, feature, bug) + "area:" labels (e.g. runtimes, category of concern (security, REST, client, ...), ...) allows me to gather and tag appropriate units of work. GitHub projects supports kanban boards and "filter by" or "slice by" features that are helpful. Pull Requests + Actions let me vet software additions. Issue/PR comment streams allow additional context capturing. Milestones & Releases let me plan larger epics and bundle my software. It's a robust digital system whose mental model makes sense in the context of delivering software.
I have an ambitious software project idea (multiplayer game software) that I'll eventually want to bring in a contractor or more. I want to stipulate some degree of interfacing with my system, even if it's just to capture the high level "this feature is handled by contractor A" and allow delegated delivery.
The points of friction so far have come from wrestling decision control with ai agents, and resisting the temptation to plan in too much detail too far into the future.
Given that brain dump, what advice might you have for me to help make for successful?
Just this week, I encountered the following problems:
- a diff showing "0 files changed" while there are many [1];
- suggested changes in a PR not rendering the original line [2];
- bug trackers not showing more than the 40th page [3].
Might seem nitpicky but it was just over the last week... I have a whole bunch of other bugs on my mind, and unfortunately, it's only gotten worse over the years. To the point where I almost don't care anymore.
[1] https://github.com/PokeAPI/sprites/pull/284#issuecomment-585...
[2] https://github.com/Delgan/loguru/pull/1516#discussion_r41268...
If GH.com is anything like GHE, the number of moving parts is staggering.
Maybe that was the point, if its not front and center then nobody will use the social features.
Regardless, I think its hard to balance UI for normies and UI for techies, I think theres also a lot of brogrammers who might think they like being techies but their version of tech is lots of padding, whitespace, diffused colouring and not information density and consistency.
Personally, I have a negative almost visceral reaction when my tools change, because I learn my tools intimately and create expectations of where things will be- but this is also why I avoid tools which don’t have consistency in their UI too.
I get design/product people sometime that get all caught up in "we need to simplify" or there's not enough whitespace. Every time, the design/product person is not a user of the product, and the result is you ship their improvements, get blistering angry feedback (last time I even got the most prolific user and recommeder of our product calling me on my cell at 11pm) and revert.
> their version of tech is lots of padding, whitespace, diffused colouring and not information density and consistency
Exactly this. I think is speaks more to how frequently the designer uses the product versus actual users, and they don't understand the difference between UX for casual/infrequent users and people who spend all day in the product.
I’m not at all. People around here love to hate GitHub, and think any change to a product or design is incredibly regressive. These to combine and people lose their minds.
Read the full thread on Hacker News →
Related stories
- Hacker News · 3 points · 3 days ago
- Hacker News · 2 points · 8 days ago
- Hacker News · 6 points · 11 days ago
- DEV Community · 18 points · 11 days ago
- Hacker News · 1 points · 11 days ago
- DEV Community · 12 points · 14 days ago