|
|
|
|
|
|
by VexorLoophole
3044 days ago
|
|
|
Dunno how i should feel about this. Somehow i got into Tech Industry without a fitting degree and found myself in a smallish (30 people) company as the only SysAdmin. Exploring, setting, and controlling all technical parts this office needs: Multiple Linux VMs with different services like smb, confluence, ...; AD- and Terminal Windows Server; Device-Managment of all used MacBooks; and so on. I always also liked to code stuff, and always found a way to archive what i tried to solve. But of course i never build something big or even though about things like super efficient ways to archive what i did. I always though that when i keep going and try to build my small personal projects, one day i can maybe start as a junior dev. Even without the degree. But your post somehow states that a junior dev has to think about edge cases even before they occur. As a Sysadmin i also have to do this. But i always imagined that the job as developer is no one man show, and that these edge cases will be found together. Code will be reworked when a more experienced team member found a pithole. |
|
|
My company doesn't really do small projects anymore, so we take a lot of care to make sure we hire people with the discipline and ability to handle large systems. There's certainly a lot of organizations that don't have that requirement, though, so some of this assessment may be a little harsh.
As for code review catching errors, that sounds great in theory, but in practice it's just rarer than you'd think. Think about it, your reviewer is always going to spend less time on your code than you did, and they're always going to have less context. I find that unless the error is egregious, it's almost never the code reviewer that catches it. You're not really a one man show, but you're pretty close.
Unit testing is by far a better approach. I catch easily ten times as many bugs in my code by unit testing it as by manual inspection and code review combined.