3 ms·

I had a similar problem, one thing I've been thinking of is how experience might be more trouble than help. IE when I first coded I used to think about * Does

by rb808 9y ago

I had a similar problem, one thing I've been thinking of is how experience might be more trouble than help. IE when I first coded I used to think about * Does it work? Now I also think about * Is it always going to work * Is it easy to read * Is it tested properly * Is it in a similar style to the rest of the codebase * Is it maintainable * Is it easy to debug * Is it DRY * Is it using the best possible libraries * Is it efficient or could I have used a better algo * Is it written in the appropriate language * Is the tradeoff between config and code appropriate * Is it easy to diagnose problems in production So slowly I became a better developer, but I reached a point where it becomes really hard to get stuff done because you're thinking about all the other stuff and trying to make everything perfect, when for many situations it doesn't have to be. Not only is all that work, but a small task suddenly becomes a huge project - and its overwhelming. Its especially difficult when you're more senior and responsible for more stuff - which you want to do perfectly too. I dont have a great solution yet. I guess I have to lower standards a bit but its difficult. So maybe its a problem you have maybe not, I thought I'd mention it anyway.

AnimalMuppet 9y ago
There are pluses and minuses. There's more to think about, true. That can slow you down. On the other hand, you don't write the bugs you used to write. You don't create the garbage architectures you used to create. You don't write the unreadable code you used to write. That all turns into work you don't need to do later to fix the problems. So maybe the question is, do you have management that looks only at how long it takes to crank out the next feature? Or do they look at how long it takes to get the feature reliably, solidly working?

by rb808 9y ago

AnimalMuppet 9y ago

There are pluses and minuses. There's more to think about, true. That can slow you down. On the other hand, you don't write the bugs you used to write. You don't create the garbage architectures you used to create. You don't write the unreadable code you used to write. That all turns into work you don't need to do later to fix the problems. So maybe the question is, do you have management that looks only at how long it takes to crank out the next feature? Or do they look at how long it takes to get the feature reliably, solidly working?