from Hacker News

Ask HN: How the hell do you stay organized as a dev?

by overthemoon on 6/21/24, 1:02 PM with 2 comments

I think of myself as reasonably competent and intelligent. I have seven years of experience. Recently I was given a task I've wanted to do for my entire career, which was being in charge of a greenfield project from the ground up that, most importantly, is not a web app. I was so excited to dig in and get away from front end development and learn a new set of skills. EOQ is next week and I'm worried I'm going to blow the deadline. This isn't the end of the world, I'm not going to get fired, but it's not great for my reputation and catastrophic for my ego. I'm looking back and trying to figure out what I've been doing wrong.

Why didn't I ask for help? Day to day, I didn't really see anything wrong. Things were progressing. One red flag that I ignored was that my manager, who I have a good relationship with, was getting on my case for not staying on top of my tickets. I wasn't updating them, I wasn't adding more when it was necessary. I just find that I go blank when I try to organize a task, especially one as large as this. I don't know how to break them down. I had an idea of what tasks were remaining, but it was just in my head. I hate--HATE--adding more points to a ticket because I feel like it makes me look incompetent as it grows and grows. At some point you're supposed to break down tickets like that, but I'm all but incapable of breaking a task down. It's either done or its not. This results in giant PRs, shambolic commits, scattered debug crap. Overall good code, I'm told, but messy sometimes.

Why didn't I ask for help? I was doing a lot of new stuff, and I learn by doing. I need to suffer at the hands of the task or I'm not learning. There's a limit to this, I know. You can only spend so long on it. I don't know where that limit is.

Why didn't I ask for help? Pride. I wanted to prove myself. I'm on a new team with people whose technical skills, depth and breadth of experience, and ability to reason about software I greatly admire. I wanted to show that I could handle a project like this, so I'd get more in the future.

Why didn't I ask for help? Where's the line between seeking help and having other people just do your job? I don't know!

So I was humming along, flitting from one problem to another, and now the deadline approaches and I don't have functioning software, I have a pile of sorta kinda there code.

Possibly relevant, possibly not, is that I was diagnosed with ADHD a few months ago. I've always known that I'm scattered and have a hard time staying on task and being motivated, but I have a job and a family, so I wasn't so dysfunctional that I couldn't participate in society at all. I got this job, after all. I'm doing okay. I knew I could be more productive, I just didn't know how, or chalked it up to requiring more willpower that I didn't have. Anyway, post diagnosis I've been working on things and it's been helping. No magic bullets, but I'm less scattered overall.

If any of this rings a bell, and you've found solutions, I'd love to hear them.

  • by mtmail on 6/21/24, 1:04 PM

    Related discussion yesterday "Ask HN: How do you stay organized for solo dev?" https://news.ycombinator.com/item?id=40742831

  • by perrygeo on 6/21/24, 2:18 PM

    Two thoughts here. First, you say you're not done and don't have functioning software yet. Sounds like you've built many of the components in isolation? A bottom-up approach can work if you know exactly how they'll fit together (either through experience or part of a well-known framework or design pattern) but it sounds like you need a top-down approach here: Build the public interface and a test harness for it first. Then fill in the scaffolding until it meets your objectives, ie commit to working software from day 1 no matter how clunky. Top-down and bottom-up approaches aren't mutually exclusive, as long as they meet in the middle somewhere.

    The second issue is more of a process one. Ask why do you hate adding points to tickets as though a ticket should be set in stone? Why do you avoid updating them? It sounds like your ticket system is providing unnecessary friction for you. This is fairly common in greenfield projects - there are so many microdecisions to be made on a minute-by-minute basis that capturing them all in tickets would be insane. Ticket systems are designed for a steady flow of bug/feature reports on existing software. So while it's nice to have the chaotic freedom of a greenfield scenario, it's usually worth it to get to "stable" quickly so you can treat it like a standard iterative project. But in that pre-stability time when the problem is still coalescing in your mind, it's a bit foolish to try and capture every microdecision in a ticket up front. You still need to capture it somewhere but it's more important to write coherent design documentation than individual tickets at this point.