I’m a Bad Developer, That’s the Only Reasonable Explanation
1–10 of 130 posts
Re: I’m a Bad Developer, That’s the Only Reasonable Explanation
#2I'd suggest trying to focus more on using tools related to building reports on code coverage and code complexity during your day to day development.
If you lean more towards a test driven approach backed with trackable metrics for code quality, I think you might have more confidence in your day to day development and ultimately be more productive.
Re: I’m a Bad Developer, That’s the Only Reasonable Explanation
#3I'd suggest trying to focus more on using tools related to building reports on code coverage and code complexity during your day to day development. If you lean more towards a test driven approach backed with trackable metrics for code quality, I think you might have more confidence in your day to day development and ultimately be more productive.
You do realise even the founder of TDD doesn't back it anymore and code coverage is a very poor metric, your words sound like a senior developer from 2010. If he's a bad developer the best he can do is read up on SOLID principles and read a book like Clean Code with good examples of how to write code.
Re: I’m a Bad Developer, That’s the Only Reasonable Explanation
#4I am not sure what this post is about. Just realise, when you are working for somebody else, of course they would like repeatable good performance from you. Some people are able to deliver this better than others. In my experience, thinking through a problem thoroughly and not giving a shit what others think is the most comfortable and most efficient way to work. Not even sure why you would consider working for somebody who stops you from going to the bathroom.
Re: I’m a Bad Developer, That’s the Only Reasonable Explanation
#5I'd suggest trying to focus more on using tools related to building reports on code coverage and code complexity during your day to day development. If you lean more towards a test driven approach backed with trackable metrics for code quality, I think you might have more confidence in your day to day development and ultimately be more productive.
You do realise even the founder of TDD doesn't back it anymore and code coverage is a very poor metric, your words sound like a senior developer from 2010. If he's a bad developer the best he can do is read up on SOLID principles and read a book like Clean Code with good examples of how to write code.
That said, from the article it just sounds like he's worked for shitty companies that don't understand the value of not writing code twice
Re: I’m a Bad Developer, That’s the Only Reasonable Explanation
#6Everyone has been put in the position of coming to a dead halt on some aspect of the work that just won't yield. Or at least not for the combination of you, your knowledge, and your resources at that given time. This never goes away. Signs of maturity as a developer involve how you deal with the existence of this phenomenon. E.g. box your time, know when to seek alternatives, and know how to find solutions that exist already, and especially know when to pull in help - and how to find useful help in your network.
The driving overall concern is avoiding points of grinding minimal efficiency for individuals, and in near all cases that can be avoided via some combination of simple strategies, even when you are the only person on your own personal project. Development is such a huge space that no two people will overlap completely in skills and experience on a team, and pulling in other people to alleviate your dead ends is a part of how you learn specifics needed to avoid that dead end in the future. But it is knowing to pull people in or seek another path that is the important part, not the specifics.
Working to an absolute dead end is only useful in the sense that you then understand better the incentive to avoid doing it again if you can.
An alternative view on the same problem space:
https://www.exratione.com/2016/01/paid-a-great-deal-to-be-te...
Re: I’m a Bad Developer, That’s the Only Reasonable Explanation
#7You could change jobs. An employer tracking your activities to the minute sounds like a cancerous work place to begin with.
Bad employers are also a thing, and is much more frequent than most people realize. They usually drown you in tools and processes along the way and without much development experience its hard to tell whether they're bad or you are.
You're going to hear about Agile, TDD, code metrics and whatnot. Its all superficial at best and those promoting them don't usually have quality products on their hands to begin with, or have codebases much larger than actually needed. At least from my experience its that way.
Its best to find an employer who can help you grow instead of fitting you in a box.
Re: I’m a Bad Developer, That’s the Only Reasonable Explanation
#8I suppose if you help someone do something they could not do themselves then you are actually a good developer, something like writing minecraft. It seems like your criteria for being a good developer is more complex, maybe even hopelessly more complex.
Why don't you try charging them 10 cents for each trip through your code? Lawyers do that, and feel like it's okay.
Re: I’m a Bad Developer, That’s the Only Reasonable Explanation
#9Good software requires teams, and teams will always vary in the member's skill levels. Some programmers are better than others -- that's just a fact of life. But even if you are not one of the best coders, that doesn't mean you shouldn't be a coder or that you shouldn't be considered a valuable member of a team, so long as you provide a meaningful contribution. You may get paid less, but that's okay. You shouldn't beat yourself up over it. Do you enjoy the work? Do you at least get stuff done, even if it is not as much as your coworker in the same period of time? Then your okay. And that's okay. You just need to find the right niche. Not every coding job is with a startup or contract firm that needs to pump out the code a mile per minute.
Re: I’m a Bad Developer, That’s the Only Reasonable Explanation
#10Estimations are a game we play. To understand how good you are, you need to figure out what's happening with the business and understand the impact you're having there.
For a small company, this is probably the rate at which you ship features. Good developers ship enough that there's pressure to constantly explain the improvement to sales / marketing.
For a larger company, this is probably a user metric. Are this things you're doing moving the needle on logins, time on site, repeat visits? You should understand what areas of the product are high value, and which are experimental. You should spend your time converting experimental features to high value features. Polish and edge cases.
For a bigco, this is probably scaling metrics, like page load time and uptime. You should have clear targets you're working against and be able to prioritize against that target. Numbers are easy to show results against.
Anybody can be fast against sprint points. You need to understand what the business goal is and play to your strengths against that goal.