Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write Less Code

mikegrouchy.com

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Write Less Code

#41

Post by anthonyb »

hcarvalhoalves wrote: post #8

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.

Good programmers hate programming? That's an over generalisation if ever I've heard one.

To be a good programmer, among other things, you need to love good code, and hate bad code.

Good code is short, neat and to the point, is well tested and well used, and helps you get things built faster.

Re: Write Less Code

#42

Post by anthonyb »

hackinthebochs wrote: post #18
jz wrote: post #7

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.

You're both arguing opposite ends of the same thing. Good abstractions are more work for the implementer, and less work for the developer using it.

The phrase you're looking for is "Conservation of complexity" :)

Re: Write Less Code

#43

Post by hcarvalhoalves »

yock wrote: post #30
hcarvalhoalves wrote: post #28

Earlier quoted context omitted.

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.

For what it's worth, I don't agree with you at all . It's like you're saying that the best chefs are those who hate cooking the most. It's a ridiculous notion that betrays a misunderstanding of the relationship between what we do and what is produced by it.

The irony is that the parallel you made with chefs just proves my point. E.g.: chefs care about delicious dishes, great presentations, evoking emotions, not keeping customers waiting, etc. On the other hand, go ask a chef if he loves chopping vegetables ;) In fact, they couldn't care less about this kind of minutae and develop techniques to do it fast and not waste time. Analogously, coding is the chopping of software development.

Re: Write Less Code

#44

Post by hcarvalhoalves »

anthonyb wrote: post #41
hcarvalhoalves wrote: post #8

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.

Good programmers hate programming? That's an over generalisation if ever I've heard one. To be a good programmer, among other things, you need to love good code, and hate bad code. Good code is short, neat and to the point, is well tested and well used, and helps you get things built faster.

Not only good programmers hate programming, they also try to make it suck less. That's when they come up with new languages, frameworks and abstractions ;)

Re: Write Less Code

#45

Post by joogernaut »

joogernaut wrote: post #39

there is no universal truth other than balance and careful judgement. Say "write less code" to the wrong person, and they will go off and create six months of meetings where they decide what they should decide what they should decide to decide to do. Analysis paralysis will creep in and kill you.

ah, the hacker news comment nazis. Forgot why I left this hellhole. Thanks!

Re: Write Less Code

#46

Post by anthonyb »

hcarvalhoalves wrote: post #29
wildtype wrote: post #5

"Code is a by-product", remind me to Atwood's Please don't Learn to code.

Code is a by-product of software development in the same sense as a blueprint is a by-product of engineering. Teaching a programming language doesn't turn someone into a software developer just as teaching technical drawing doesn't turn someone into an engineer.

I think you're being a bit free with the metaphors here.

A blueprint isn't a finished deliverable if you want something that you can actually use. Code, on the other hand, mixes design and building - if you delete the code, what are you left with?

Re: Write Less Code

#47

Post by evincarofautumn »

getspeedly wrote: post #32
evincarofautumn wrote: post #10

Earlier quoted context omitted.

I’m with you. The most rewarding thing about diving into a large codebase is that you have many opportunities to refactor while you add features. At my current job I add only marginally more code than I delete. Feels good. :)

Sure -- as long as there are tests and some semblance of order. Trying to add new features to an untested ball of mud is just about the worst possible thing one can inflict on a poor programmer.

Yeah, luckily, the guy I’m working with is quite good about testing. If that weren’t the case, then I’d have a different opinion…

Re: Write Less Code

#48

Post by hcarvalhoalves »

anthonyb wrote: post #46
hcarvalhoalves wrote: post #29

Earlier quoted context omitted.

Code is a by-product of software development in the same sense as a blueprint is a by-product of engineering. Teaching a programming language doesn't turn someone into a software developer just as teaching technical drawing doesn't turn someone into an engineer.

I think you're being a bit free with the metaphors here. A blueprint isn't a finished deliverable if you want something that you can actually use. Code, on the other hand, mixes design and building - if you delete the code, what are you left with?

Yeah, I'm playing with metaphors here. The point I want to get across is the code itself is just a means to an end. Just the code is often not a deliverable, unless you make money from software patents. Google doesn't make money because they sell a lot of code. Facebook doesn't get investment because they wrote a lot of code. That doesn't mean their code isn't valuable - it is. But it's the actual computation (e.g. execution of this codebase) that has real value. Get it?

Re: Write Less Code

#49

Post by itisfritz »

ilaksh wrote: post #38

If you find a way to avoid writing ASCII codes, or avoid it most of the time, then you aren't programming. And therefore, you are no longer a programmer. Arranging, configuring and connecting components/widgets with GUIs is a very powerful way to solve all sorts of problems in many application domains. Unfortunately, the more powerful a system like that is, the less attractive it is for 'software developers' because…

>https://vimeo.com/43784316

this sucks dick

Re: Write Less Code

#50

Post by anthonyb »

hcarvalhoalves wrote: post #48
anthonyb wrote: post #46

Earlier quoted context omitted.

I think you're being a bit free with the metaphors here. A blueprint isn't a finished deliverable if you want something that you can actually use. Code, on the other hand, mixes design and building - if you delete the code, what are you left with?

Yeah, I'm playing with metaphors here. The point I want to get across is the code itself is just a means to an end. Just the code is often not a deliverable, unless you make money from software patents. Google doesn't make money because they sell a lot of code. Facebook doesn't get investment because they wrote a lot of code. That doesn't mean their code isn't valuable - it is. But it's the actual computation (e.g. e…

That attitude leads to devaluing software, followed by bugs, a legacy codebase and not being able to extend your software when your competitors catch up. Programs and the problems that they solve are intertwined. You can't easily separate them - which is why your metaphor doesn't work.
Post reply on HN