DEV Community

Discussion on: I am a mediocre developer

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

These are habits of any successful developer. If a rockstar devleper thinks this stuff is unnecessary then they are dillusional and setting themselves up for failure.

I look up functions, syntax, and algorithms all the time. Sure, as I get into a project I'll start remembering the common stuff, but it's not ingrained in some permanent memory somewhere. I'll lose it when I move projects.

What I tend not to look up are paradigms, patterns, and structure. This stuff is universal and difficult to search for. It's the type of question they close on StackOverflow. How much of this stuff you can keep in your head will impact your overall ability. It's a huge part of what must be "learned".

I don't trust my code either. It's not just my code, I don't trust the framework, I don't trust the OS, I don't trust the user, the environment, everything. I assume everything will break because it eventually will. I focus on test/use-driven development. I consider code reviews hugely beneficial. Defensive programming is a must.

Some people may think this slows you down, but I consider it speeds me up. By following a checked development practice I can be assured I'm not spewing out crap, nor do I need to second guess myself. Good practices help free my mind from clutter.

A side-note to the WTF/Minute: I believe one should develop a coder empathy. Don't judge your code from your viewpoint, but from others. There's plenty of code I've written that I have no problem understanding, but I know will confuse others, and probably even me in a few months time. Though it's not always easy to make the distinction between necessary and needless complexity.

Collapse
 
ssommerit profile image
Shawn Sommer

I've always been the same way regarding trust. It seems the minute I trust that something will work as it is supposed to, it doesn't.

Dovetailing with this idea, my first boss often complained that things took "longer than they should" when I worked on them. But then when it came time to discuss my performance for the year I would be pretty much with everyone else in terms of completed items. What he was initially missing was not only that I would dig to ferret out the real problems rather than treat a symptom but I would also go over it a few times and think about edge cases, etc... That made it rare for a ticket to come back to me after I had completed it where many of the other "faster" devs would end up revisiting the same ticket 5 or 6 times because they were trying to work fast. Sometimes we would joke when a dev would hit a rough patch where it seemed nothing they did was passing QA calling the offender "Captain Rework".

Also, we shouldn't fool ourselves into thinking "a user would never do that". We had an end user that would literally wait for an update to come out and then he would actively try to break it. We'd literally get tickets where he'd say something like "I put 55 question marks in this field and tried to submit the form, my browser became unresponsive and crashed. When I put in 54 or less it works fine, please fix." I mean really, who does that? lol