Ask HN: Why am I such a bad programmer?
Hello.
I signed up with an anonymous account because i’m ashamed of myself. My co-worker tells me that i’m a really bad programmer. He says that my code is WET and full of leaky abstractions. What should I do?
Please help me
Thanks.
24 comments
[ 5.6 ms ] story [ 65.2 ms ] threadwhere can i find them? do you know what WET means?
In my humble experience, anyone who can't constructively criticize others' code is probably a bad programmer themselves.
You may very well be a bad programmer. Almost all of us are. It is good if you are perfect out of the gate, but it is also good to get things done, and keep improving.
Can you ask him how to make your code better or point you to resources that might help?
How long have you been writing code? Maybe it will just take time and experience to improve.
There have been some long threads here about other people's evolution as programmers and what kinds of things they felt helped them improve. I don't have one in mind right now, but maybe you could find one.
You could also try reading a couple of software engineering books that talk about some of these concepts. Wikipedia mentions The Pragmatic Programmer, and there's also Code Complete and others. (I haven't read either of those.)
Here's a list of the best "software engineering" books, although the focus of these is incredibly varied and some probably wouldn't be relevant to you.
http://noop.nl/2008/06/top-100-best-software-engineering-boo...
Thank you. I have read the wikipedia entry but I have to say that DRY seems obvious to me. Is this really a thing? Am i missing something? I just try to write code that is easy to read. And I try to reuse code as often as it makes sense.
That list of books looks good by the way. Thank you
Learn new tools frequently, and apply lessons from new languages into old languages.
Write your own compilers and interpreters, in order to understand the requirements, expectations, difficulties, and habits of compiler and interpreter implementations.
Design your own languages, in order to understand the requirements, expectations, difficulties, and habits of usable language design.
Give yourself at least ten years to become a half-decent programmer. Anyone who considers themselves half-decent who hasn't been doing it for a decade is probably kidding themselves; anyone who is considered by their peers to be half-decent who hasn't been doing it for at least a decade is probably surrounding themselves with incompetent peers.
Listen to your coworker. Get his specific complaints, determine what general rules you can gather that would assuage his concerns, and ask him if those general rules are the correct ones. If he can't give you specific complaints and general rules, he's talking out of his ass and playing status games; if he can, then no matter his manner of speaking, his criticism is constructive and valid. After all, bad code is a big problem, and at best puts extra work onto your coworkers.
If you cannot ask your coworker what he means by his criticisms, then you're probably sunk, unless some other coworker can explain it. But, as a junior dev, your code probably is bad -- the state of the industry is bad, and most code is awful, including that written by people who are ostensibly senior -- and you will benefit immensely from learning to write better code.
I wrote a Lisp interpreter once. It was fun! I have been coding for 10 years by the way. How do I know if my code is bad, or if my coworker is just being judgmental (as some people here are suggesting)? Are you a good developer?
Thanks
information latin: informatio, from the verb informare. information is that which informs!
informare in-: in (into) forma: forma (a form)
Something is missing; informare, into a form.
ddorian43, I inform you: I am trying my best. Let me explain:
Information can be thought of as the resolution of uncertainty. The maximum of information coincides strangely with maximal unpredictability or noise!
What else? Claude Shannon proved in 1937 in what is probably the most consequential MA thesis, that simple telegraph switching relays can implement by means of their different interconnections the whole of Boolean algebra.
Eleven years later the same Claude Shannon published an even more groundbreaking paper: "A Mathematical Theory of Communication". The paper asserts that:
"The fundamental problem of communication is that of reproducing at one point, either exactly or approximately, a message selected at another point."
We all know how influential this is, right? But is it enough info(rmation)? ¯\_(ツ)_/¯
Also, when you have an abstract data type, and you hav a memory leak, it is called a leaky abstraction.
Your coworker is a great person and you should try to convince him to adopt you as only he will show you how to be a great boy!
Now get outta here and go play!
It's important to know why the code you've written is not considered good, so ask your co-worker about the problems he/she has noticed. If they are legitimate problems then highlight them with your line manager, and offer a solution/fix that will improve your code. No one is perfect, and more often than not good programmers are those who iterate and adapt to changing requirements. If they notice problems with their solution, they'll happily point them out, and will offer a solution.
Ask what you can do to fix the problems, and once you have your solution it's unlikely that you'll make that problem again.
It's entirely possible that your co-worker doesn't know what would improve your code, but simply knowing that it can be improved can be a useful thing, as it urges you to explore other options. Since your co-worker has said that your code is "WET" (I assume the opposite of DRY?) this should lead you to look into what makes code DRY in your language, and through this, learning if your code is repeated for a reason or not.
As a personal anecdote, on a recent project a junior developer slated some of my Razor code because I wasn't using EditorTemplates for the forms on the site. After a month or two on the project, that developer quickly learned why I didn't bother with EditorTemplates. Fields that seemed similar weren't similar at all at times. The project requirements were changing weekly, and ultimately I was able to make changes quickly while he was fiddling with his DisplayTemplates/EditorTemplates, trying to make them work reliably across multiple different scenarios.