21–30 of 54 posts
(I got this from akkartik but can't remember where.)
Earlier quoted context omitted.
"I wouldn't say "hate" programming, people who hate programming tend to write the worst overcomplicated code (...)" No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard. "Persuading people not to add functionality they don't need is a good idea of course, but this isn't always going to be practical. Firstly…
No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard. I guess it depends on how you define "hate". The amount of effort you put into your job tends to some function of how much you enjoy it and how much money you are paid. At a certain point the money tends to tailor off in effectiveness too. If you hate yo…
If I could build great software without writing code I would. Unfortunately we're not there yet. As you said it yourself, most businesses now depend fundamentally on software. So being inside and working to make your code base as good and maintainable as possible, and understand those processes is important. So we do care about writing good software. But not because we love writing code, but because we hate that.
Earlier quoted context omitted.
No, this is just being slopy. Developers who "hate" code will always push to deal with the smallest amount of it, so they think twice before they touch the keyboard. I guess it depends on how you define "hate". The amount of effort you put into your job tends to some function of how much you enjoy it and how much money you are paid. At a certain point the money tends to tailor off in effectiveness too. If you hate yo…
You don't have to love the ride to enjoy the trip. Programming is just a means to an end. We love the end, not the mean. He's not talking about worrying "how soon can I go home today". You do have a powerful motivator, which is the awesome software you're gonna build. You wanna write code because you wanna see your own thing built and working. Not because you love writing text on the editor. If I could build great so…
In fact this is probably a big motivator in the number of open source libraries available now, they were developed by somebody who wanted to achieve thing X but they needed to create byproduct Y in order to do that.
So it makes sense to share by byproduct Y with the people who need to make thing Z.
Some of my favorite quotes about programming ( http://quotes.cat-v.org/programming/ ) make precisely this point: " One of my most productive days was throwing away 1000 lines of code. " -- Ken Thompson " Deleted code is debugged code. " — Jeff Sickel And probably my favorite (because this doesn't apply only to lines of code): " The cheapest, fastest, and most reliable components are those that aren't there. " -- Gord…
Just to clarify. I think what he means by that statement is that, we assume that components not yet built would be cheaper, faster and more reliable than they would be in reality. Which is almost always true.
[EDIT: Just realized, it's true the other way around too, if you eliminate the need for a component, it becomes the cheapest, fastest and most reliable component.]
Earlier quoted context omitted.
Part of the zen of Python is "Flat is better than nested". Until recently, I always thought of this at a code block/function level. Recently I realized that this is also important when modularizing and adding layers of abstraction. The more layers of abstraction (from foo.bar.baz import Baz) you add, the more code you write and have to "keep in your mind". This presentation by Jack Diederich at PyCon 2012 really open…
Interesting you say that; I would argue (and have) the exact opposite. Good abstractions, by their very nature, reduce the amount of moving parts you have to keep in your head at any one time. When the number of "moving parts" created by your abstractions outnumbers the actual bits its abstracting, then you know your design took the wrong turn somewhere.
This is an interesting point which I agree with and is usually where I end up. In the past I've started from the opposite end, creating multiple modules, class hierarchies, etc. This future proofing has made things harder for me to follow/understand when reading at a later date. It has become tiresome and now I consciously start at the other end, making the simplest thing that could work. Layers of abstraction then come naturally as needed.
I agree with the advice doled out by the author about spending more time on thinking than actual programming. This is something most good developers eventually learn as they get more experienced. To immediately dive in and implement as you find issues would cost you more time in the longer run.
Also, putting it on paper always helps. Especially when you're dealing with large software or changes to complex algorithms. It helps to visualize it on a more permanent medium than the brains fickle whiteboard.
Ultimately, unless you work on the software like you have a stake in it, you wouldn't spend enough mind on it to do the continuous re-factoring and improvements it takes to make great software. This is especially true in a commercial environment where deadlines and releases and user visible improvements are the focus of the management. It is upto you to care about what happens under the hood and eventually you will wish you had.
Earlier quoted context omitted.
Interesting you say that; I would argue (and have) the exact opposite. Good abstractions, by their very nature, reduce the amount of moving parts you have to keep in your head at any one time. When the number of "moving parts" created by your abstractions outnumbers the actual bits its abstracting, then you know your design took the wrong turn somewhere.
> When the number of "moving parts" created by your abstractions outnumbers the actual bits its abstracting, then you know your design took the wrong turn somewhere. This is an interesting point which I agree with and is usually where I end up. In the past I've started from the opposite end, creating multiple modules, class hierarchies, etc. This future proofing has made things harder for me to follow/understand when…
At that point you can introduce bugs because somebody modifies the old code in a way which would not be allowed under the new abstraction and then the new code ends up reading data produced by the old code leading to a cascade of failure.
I would go even further: to be a good developer you have to hate programming. If you like to fiddle too much, you'll waste time messing around and bikeshedding instead of taking your time to think about the problem at hand at a more fundamental level. Sometimes you solve a programming issue without writing even one line of code, but challenging the business requirements instead. It's important to be holistic.
Not to be a pedant, but I think you meant "yak-shaving" (1) not "bike-shedding" (2) . Shaving yaks is fun. A little too much fun. Bike-shedding is always misery. (1) http://en.wiktionary.org/wiki/yak_shaving* (2) http://en.wiktionary.org/wiki/bikeshedding*
"Code is a by-product", remind me to Atwood's Please don't Learn to code.
Earlier quoted context omitted.
Not to be a pedant, but I think you meant "yak-shaving" (1) not "bike-shedding" (2) . Shaving yaks is fun. A little too much fun. Bike-shedding is always misery. (1) http://en.wiktionary.org/wiki/yak_shaving* (2) http://en.wiktionary.org/wiki/bikeshedding*
Thanks, but I really meant bikeshedding - that is, people who "love" coding tend to also "love" wasting time in the details instead of focusing in the big picture.