HN Explorer

Ask HN: How to manage expectations when inexperienced?

2 points by ssmmww ↗ HN
I am a math grad with reasonable coding skills and a nontrivial amount of CS education, but no real-world development experience. I've completed a few personal projects of various degrees of complexity, but that's it.

I might soon be getting a part-time/contract position as a full-stack developer. I would be working alone to build a small prototype of a moderately complex web app. I'm about 70% sure I can do it, but I'm not completely confident: it would be my very first paid programming job, after all.

My concern is that my prospective employer, who is an entrepreneur with no background in tech, may have unrealistic expectations of my abilities. I've been completely honest with her about my background, but with no experience, I feel like an impostor or a fraud.

What if the project turns out to be more complicated than either of us expect it to be, or I have overestimated my abilities, and I can't make any progress? Is it unethical to take on a contract job you're not 100% sure you can finish? Are these just completely normal anxieties that everybody has at some point?

Any thoughts would be greatly appreciated!

2 comments

[ 3.6 ms ] story [ 20.7 ms ] thread
matt_s
I think if you set expectations that you both will be learning together (about the tech) as you go and that there 100% will be some unknown roadblock you come across it might help.

Everyone feels like an imposter and that is a good thing compared to being over-confident and unaware that you are implementing things in a poor manner.

My advice would be to start small and follow agile principles as you go. You don't need formal SCRUM or other methodologies if you are the solo dev but you should build things in vertical stacks. By that I mean as an example: a feature is logging into the system, build that out so it is ready to ship. Sure you don't have other features at this point (its just an example) but you should have the UI, server-side handling of data and database parts all figured out to the point that you could ship it if you want.

It's like breaking a large math problem down into more manageable parts - same thing with developing the software. Small, shippable, testable parts.

Figure out your deployment process, this often isn't taught in CS and is more of an "ops" thing. This will help make it easy to ship new things into your environments AND to roll it back if things are messed up. It is liberating to know you can just type a couple commands and restore things - you feel more free to make mistakes.

kreetx
Even if I don't like it much myself it could be good to estimate the tasks -- just to see where you fall with the results. If you're both learning you'll get a good grasp on how long things might take, and why. And while you're finishing single tasks you can re-evaluate the ones waiting in line -- accounting for what you have learned.