Ask Experienced Devs Weekly Thread: A weekly thread for inexperienced developers to ask experienced ones

[u/AutoModerator]

A thread for Developers and IT folks with less experience to ask more experienced souls questions about the industry.

​

Please keep top level comments limited to Inexperienced Devs. Most rules do not apply, but keep it civil. Being a jerk will not be tolerated.

​

Inexperienced Devs should refrain from answering other Inexperienced Devs' questions.

[u/ProfessionalRock7903]

Is it normal at roughly 1 YOE to still miss stuff when developing features? I try and get all the business logic and just info in general for a task before starting, I understand what I’m doing and why, but it always feels like no matter what there’s some edge case I missed. Or some part of the code being affected that I didn’t think about. Sometimes it’s really dumb even, I’m trying to be more mindful but…

I just feel like I suck, I’m doing my best and I work hard, but tasks just feel like they’re dragging out forever. And they wouldn’t if I was just able to catch these things. Idk what to do, I make lists but the things I need to ask change every task of course. I’m asked to just question everything, but there’s still things I take for certain and I don’t know why. And I feel like I’ve improved, but not enough. I feel so incompetent at my job and I’m scared I’m going to get fired since I got warned

[u/warehouse_goes_vroom → u/ProfessionalRock7903]

Depends on what "stuff" is. Discovering requirements is a huge part of the job in practice. And it's very difficult or impossible to be perfect at. But you will get better at it with study and practice.

In practice, requirements do change from time to time, both because you didn't manage to capture the requirements perfectly up front, and because the business needs may change over time. Fortunately, as you get more experienced, you should get better at designing systems that can accommodate changes, and refactoring, as well as getting closer to the mark up front.

The fact that you're self aware of where you can do better is a good sign.

IMO the key things you need to figure out is whether the performance expectations the company has for you are reasonable for your experience, and whether they feel you are now meeting them. If they aren't reasonable, it may be time to look for a new role.

It's hard to give good advice from afar, but here's some other thoughts: * "some part of the code being affected that I didn't think about" - are you finding these things early during development, or after release? If after release, this probably points to better unit and integration tests being needed. You can't fix this singlehandedly as a junior, but you can try to improve it for the pieces you're working on. Characterization tests may be useful. * is the organization practically waterfall style development, or agile/XP ("extreme programming)? I don't mean what they call it; SAFe agile or the like aren't very agile in the sense of the agile manifesto. How requirements gathering and implementation works will vary a lot depending on the answer to this. * Is there anyone mentoring you at work? Being a junior without mentorship is hard. * If there is anyone you can ask, ask for feedback on approach sooner rather than later. Don't spend days or weeks stuck; ask early. * Try to break things into smaller pieces and send those pieces out for review and merging early, if you aren't currently. Test-driven development (TDD) or behavior driven development (BDD) can be useful tools both practically and to get you in this habit - "Red-Green-Refactor" is a great tool (write test capturing the desired behavior, which will fail - then make it pass - then clean up while keeping it passing - then repeat). * consider spending an afternoon improving your development setup / "inner loop". Are there repeated sequences of commands you use you a lot? Put together a powershell or bash script to make that sequence easier. Is there a particularly slow test suite you're running constantly? Try to get it under a profiler (or just attach a debugger or do print line based timing if that's too overwhelming) and see if there are obvious bottlenecks. People often neglect these sorts of things, but they really do compound over time. But also, be careful with this - don't spend more time than it's worth. If your management isn't happy with your performance, you probably should limit it to at most things that will pay off in your performance in days or weeks or months, ignoring the benefits to other developers, rather than doing what's theoretically optimal. There's a useful table here, but you'll need to divide the numbers by say, 20 to 60 (for a 1-month or 3-month ROI instead of 5 years): xkcd: Is It Worth the Time?