Comment by pier25 | Hacker News Reader

Comment by pier25 | Hacker News Reader

Parent Full thread

I've been doing 100% full stack while bootstrapping my current project for the past year and a half. So basically doing absolutely everything alone.

It's really exhausting and progress is extremely slow. It's not a matter of skill or knowledge as I've been doing design, front end, and general programming for 20 years. At first I thought it was because I was on my own, so the workload was tripled, but then realized a major factor is really the cognitive cost of having it all in my mind. The db, the platform, the backend logic, the API, the frontend code, the design, the UX, etc.

Now I try to not work on the whole thing at once. I focus on the backend for a couple of days, then on the front end for a couple of days, etc. This works, but there are many times where something doesn't work as expected and I need to switch between multiple projects (front, API, some other service, etc) during the same hour.

I really don't have a solution to this problem, but I wanted to share my experience. Hopefully someone who has been doing this juggling has some wisdom to share.

Hire a contractor or junior dev. Even if they aren't good at what they do, the very act of waking up in the morning to have a check-in and answer questions will motivate you.

Most solo devs/founders don't do this because they feel that an employee will only slow them down and degrade the quality of the product. However, this isn't true. You will wake up more motivated every day, learn about communicating needs, and you will often receive very important feedback (like when a feature makes no sense).

If you can't afford to pay a junior dev (even off-shore), you should assess your business strategy because this means you are likely to be financially precarious or dangerously risky

It's a good idea, but it doesn't really solve the cognitive cost I'm describing.

This is very familiar to me, I've been trying to use some strategies to limit cognitive load to mixed success.

The most effective thing has just been taking better notes. If i know i take good notes, and i write something down and know i will go back and read it, my brain knows it's "allowed" to forget about it, and that greatly lessons the load. Sounds obvious and simple but sometimes it's not obvious that spending time to write down a mix of both really basic and really complicated stuff can make it so much easier to get stuff done.

This is the key for me, but I've never heard anyone else talk about it. It feels like I need to get it out of my brain and somewhere else or my brain's 'ram' is full. I'm not sure if its mental of there is some physiological phenomenon going on there, but it really works for me.

You mean like documentation? Or what type of notes are you talking about?

Documentation would be a part of it but not really what im talking about. First step would be learning to recognize the thoughts that keep buzzing around in your head, like if are frequently noticing that you keep thinking "I gotta do X, which requires me to do Y, and this is how i should do Y but im not sure about Z and whether or not i do Z or Y first so now im thinking about how i should do Z".

Then those things need to get offloaded to some kind of note system. Just a text file can work, or a doc, or a paper notebook... It's good to write down the things you need to do, but also anything important about how you wanted to do them, or any inter-depencies you might forget about if you "offload" them now. Any thoughts you are 100% confident you can regenerate trivially dont get written down.

Once you have them stored, you need to mentally recognize that you no longer need to think about those things. It's kind of vague but thats the best i got. Then all the space it was taking up is free, and you're free to focus in on something more specific.

Thanks. It makes sense. I will try your method and see if I can offload some RAM!

I've gone through a similar process. For me what you described of splitting it into the tangible parts helped a lot - I'd spend a week just working on the back-end and then a week on the front-end and vice-versa. Was hard to context switch between the two (especially as my back-end is usually python and front-end is usually a flavor of JS).

I spend a lot of time designing the thing I am trying to build to be spread-out vs built-on-top. This way, I have a big list of fun and interesting problems to solve, after which comes the gluing them back together for the prestige.

In reality, it never quite works out that way - but I still maintain it is a good way to start. Like many have said, it is essential to identify the path by which you multiply engineering as demanded by the needs of the thing you are building.

Many projects can keep that factor to 1, but it has to be about the love of doing it, not the outcome. The minute the outcome is more important, hire, scale and delegate!

Why would you try to "keep it all in your mind?" Document. Wiki. Code comments. Good commit messages. Etc. Use a task/issue tracker. Whether that is a text file, Trello, or whatever. Track progress.

Of course I have documentation.

What I meant is that when working on certain features you will need to understand it all to implement it.

It's like when you're working on some code and you need to understand all the classes and abstractions involved to make it work.

> What I meant is that when working on certain features you will need to understand it all to implement it.

That's more or less true regardless if you're soloing a project or on a team. Depending on the design. It's true, you do sometimes, for a period of time, have to keep several things in your head at the same time, but how the code base, class, function, or whatever, is structured, can increase or lessen this cognitive load. There's many ways to skin this cat. Generally you shouldn't have to keep more in your head than the current module. It's all about encapsulation. Do you need to understand just the interface, or the implementation as well? That's your choice, as far as how you design your codebase, since you're a solo dev.

Reply on news.ycombinator.com