This "young'in" seems to be learning ... with a few more insights we'll have to promote him to management so he doesn't accidentally share this knownledge with anyone.
Lessons after five years of professional programming
21–26 of 26 posts
Re: Lessons after five years of professional programming
#22I'll second the Rich Hickey shoutout at the end. I've been listening to everything I can get my hands on from him recently. He is brilliant.
Re: Lessons after five years of professional programming
#23I may be interpreting them the wrong way, but whenever I see articles about wisdom accrued after X years programming where X What's the difference between an article like this and something by Carmack? The true veteran doesn't usually write pithy numbered lists to follow (and usually, they don't write articles at all, it's someone interviewing them). They teach by example. They explain a situation, what their problem was, and how they solved it. This allows the reader to really see why it was (or wasn't!) a better choice, and understand where it may or may not be appropriate in their own circumstances.
I guess it boils down to me thinking that anyone willing to write a list like this probably knows just enough to be dangerous (which items on this list could be, depending on how they are interpreted). So again, wait another 5-10 years and then see what you have to say on the subject.
Re: Lessons after five years of professional programming
#24I agree with #12 and although it is important to enjoy your work, I find it is very useful to take initiative and really think about "Why" you are doing something. The "Why" helps me get past many hurdles, keeps me motivated even during boring tasks, and almost always ends in a result I can be proud of.
Re: Lessons after five years of professional programming
#251. When performance is an issue, if you can calculate or process it at the application layer, then take it out of the database layer. order by/group by are classic examples. It’s almost always easier to scale out your application layer than your database layer. As true for MySQL on your server as it is on the sqlite in your handheld. I disagree. RDBMS are highly optimized for this kind of operations (including MS SQL…
> Code should be self readable, and if you get > to the point where it isn’t, then you may have > to rewrite few bits. This is not always > possible though, especially for temporary > hotfixes or hacks. In this case, comments are > a must. * Sometimes business decisions may not make logical sense, but someone says "do it this way." It makes sense to comment this in the code. * The code might tell you what it's doing,…
Toes agree. It's the why you are deciding to do something a certain way that's important.
Re: Lessons after five years of professional programming
#261. When performance is an issue, if you can calculate or process it at the application layer, then take it out of the database layer. order by/group by are classic examples. It’s almost always easier to scale out your application layer than your database layer. As true for MySQL on your server as it is on the sqlite in your handheld. I disagree. RDBMS are highly optimized for this kind of operations (including MS SQL…
> Code should be self readable, and if you get > to the point where it isn’t, then you may have > to rewrite few bits. This is not always > possible though, especially for temporary > hotfixes or hacks. In this case, comments are > a must. * Sometimes business decisions may not make logical sense, but someone says "do it this way." It makes sense to comment this in the code. * The code might tell you what it's doing,…
Agree - but ideally these are just few exceptions. If these practices take over, then we may have a bigger issue to deal with and have a look at some serious refactoring of the infrastructure. e.g. too many legacy components may just require some rewriting or, if not possible, some kind of wrappers or facade patterns that makes the behavior self-readable (to the point where the legacy code is used).