
Ask HN: I'm leading the app development as a jr dev. How do I not screw this up? - TbobbyZ
I&#x27;ve only been coding professionally for a year. I know how to write some basic server code, am familiar with rest apis, have built a few web applications with react and angular, and have a general understanding of full stack development. I have no college degree.<p>My professional job that I code for doesn&#x27;t pay me that well, so I work in the evenings as a cashier at a family owned restaurant, they have 7 other locations. I met the owner and told him I have some ideas for web apps that can solve some of their problems.<p>After having a meeting with the owner today, he said he has at least a year of development work for me and that I will be leading in creating apps that work with all of his store locations. By leading, I will be doing almost 100% of the development by myself.<p>Apps that will be built: for inventory management and ordering, employee training, customer surveys, and others that are related to running a restaurant businesses. I told him there would be value in gather all the data from these apps and use it for understanding how to improve the business (data science).<p>This is obviously a great opportunity for me. My employer is aware that I&#x27;m at a junior level, but wants to give me a shot to grow with the company. I&#x27;m stoked.<p>How do I not screw this up?
======
smt88
Rely heavily on open-source software. Use your skills to tie existing
libraries/apps together instead of starting from scratch.

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.

------
namuol
First rule: Your job is to solve their problems, not to build software.
Software is just sometimes a viable solution.

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.

------
lwlml
Read "The Phoenix Project" and everything you can get on "Continous Delivery",
"Kanban" and "Agile Testing." You'll want to know how to set up your safety
nets--even if you are doing 100% of the development by yourself.

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.

~~~
TbobbyZ
"The Phoenix Project" look like a great book! I'll give it a read. I'll
definitely be requesting a pay increase after successful completion of their
first app.

------
anigbrowl
Get two people onto the team immediately so that you have a scapegoat
available for when things inevitably go wrong.

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.

~~~
TbobbyZ
You want someone else your team just to blame them if things go wrong. Are you
serious?

~~~
anigbrowl
No. That was why the next paragraph began 'Seriously, ...' and went on to talk
about good practices and personal responsibility. It was a joke, rooted in the
widespread experiences of such practices among bad managers.

This is called deadpan humor and it's wise to look for additional data for
comparison when you see someone make a superficially outrageous or incongruous
statement.

