Ask HN: I'm leading the app development as a jr dev. How do I not screw this up?

Practice TDD, even if it takes longer to deliver something. Write thorough integration tests. If you don't, you are guaranteed to deliver products with lots of bugs. Tests are the antidote to anxiety or feeling like you're in over your head.

Use a stack with excellent static typing, like TypeScript, and take advantage of that typing. Again, do this even if it takes longer to deliver the first iteration of the product.

Estimate how long something will take you and then quadruple it. I'm not kidding. If you honestly think it can't take longer than a week, promise to deliver it in 4 weeks. A business person will rarely say, "It shouldn't take that long." If they do, just make something up about how it's more complex than it sounds.

If you deliver early, you're going to look awesome. Most of the time, you'll use the entire 4x estimate.

That's all I've got for now. Email me at the address on my profile if you have more questions.

1. List all the problems the business wants to solve

2. Consider non-software solutions, especially anything that would eliminate the need for software.

3. Look for existing software solutions for any of the remaining problems. This especially includes simple things like spreadsheets, or slightly more sophisticated tools like AirTable.

4. Finally, for the _very_ specific problems you need to solve, consider the smallest piece of highly-specialized software to solve this problem

5. Avoid combining all of the solutions into one big project; it will only make it harder to work on and maintain in the years ahead.

The Phoenix Project is especially relevant since there are extremely stressful situations the characters experience. When you are "Jr-level" you need all the case history you can get your hands on in order to get experience. Find other people's painful experiences and retrospectives so that you can realize when you are in serious trouble before things get out of control.

It is one thing to kind of be good with doing application development or full-stack development, but you'll find there are a lot of other "soft skills" (which is another excellent book to look for) that you will need to practice.

In short, you've got a lot of work to do! And be wary of anyone who claims "they've got a year of development work" in the faucet waiting to be poured out--this may just be an enticement to keep you around... cheap.

Seriously, though, communication is the key. Build out the most detailed to-do lists you can for yourself and potential team members, and don't forget to budget for boring things like documentation, code commentary, testing and so on, Pad your time estimates for each part by a factor of two (or more) to reflect your inexperience and uncertainty - never ever ever fall into the trap of thinking 'this'll be quick and easy', that's often a sign that you haven't fully thought through the problem. Also have a strong backup strategy for situations where you put code into production and it fails, especially the circumstances where it works fora while and then falls over - you don't want to be trying to decide to between whether to revert the code base or lose critical business data.

Then make a shorter summary version and discuss that with your employer. Be frank with him about both your excitement but also your worries, and try to figure out a protocol between you about what to do when there are problems. Ask him about problems he's had in the past with other people and what did or didn't work. Also agree something about working standards and so on so that you don't put yourself into a burnout situation, which is a particular problem if you're the new hotness.

Lastly, really really work on your people skills. Take time to understand other people's needs in different departments, and when you want to innovate ask how best you can support them through that change, and again what good or bad experiences they may have had in the past. If you're young, this is a great opportunity to give up Bullshit - the impulse to always give an answer, even if you are making it up as you go. Even though you'll often be right, and though it might be sincerely intended as a good answer, the tendency to produce a novel answer on the spot is very seductive because it makes you look and feel clever - but if it turns out to be incorrect then you are in a real bind, and have to either deal with shame for admitting you messed up or try to cover your tracks, which often makes things worse (see the world of politics for innumerable examples from all politicians).

When you step into a position of responsibility - and this is not just true in the workplace but in your personal and civic life - one of your most valuable assets is the ability to say 'I don't know' and then deal with that reality. At first you'll get some pushback from people - clients, colleagues, whoever - who'll question your abilities or skillset, but it's always better to acknowledge uncertainty and deal with it than to bluff your way through. People are superficially impressed by bullshit artists but once the inevitable letdowns occur, they really really hate the feeling of having been lied to, and eventually that toxicity is a killer. The joke I made at the beginning of this post is the bullshit artist's default mode of operation. Stay off that path, work hard, and things will be fine.