Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
HOW-TO: Be A Great Programmer And Win At Life

By Dont Fear The Reaper in MLP
Fri Jul 01, 2005 at 12:12:15 AM EST
Tags: Software (all tags) 		Software

Bram Cohen (yes) on what makes great programmers:

"What truly separates the great programmers from the journeyman programmers is architecture. What's puzzling is that architecture appears to be one of the simplest parts of the whole process, requiring in most cases little more than some pencil and paper calculations and a willingness to change."

A little later:

"My advice about technically unjustifiable architectural decisions is to not do them. If you find yourself doing them, you probably need to get laid or see a shrink or have a beer." [ link ]

Would programmers become better programmers if they would just lighten up?

It's so easy. Use the right tool for the right job and all that, right? We all know this. But do we really believe it?

Bram seems to be advocating thinking in a requirements driven way. Take the requirements, empty your mind, then work on creating an architecture. Know what the real goal is, and forget everything else.

It's not about a prison for your mind, it's about the prison of your mind. You've øwned yourself, there is no spoon.

This approach is similar to what Chuck Moore does with his Forths. His motivation is brutal simplicity, also driven by well defined requirements and the willingness to dispense with anyone and everyone's favorite sacred cows. Do not generalize unecessarily, do not try to solve any problem except the one you are actually supposed to solve. Do not waste time trying to use other people's code, or even your own old code. Refactor, refactor, refactor.

Of course, the general consensus on Chuck Moore (from those that have even heard of him) is that he's kind of a nut. After all, he claims that his approach pretty much solves The Software Problem, and we all know that there is no silver bullet.

There are some smart people working on The Software Problem.

Is it really a Zen thing? Are the biggest barriers the ones you yourself have carefully built up in your own head? It seems possible. After all, we're talking about the thinking involved in writing software here, not levitation. It's all mental.

What if the requirements are bad, or constantly changing? Isn't that the reality in most of the software business? Or is the reality that software written for the large and complex - and thus poorly defined and understood - general case will always do things that we don't expect and don't like in the real world? What would happen if software businesses told their clients as much? Would they simply lose the job to someone who was happy to charge lots of money for what the customer thinks they want? Is off the shelf software more cost-effective than custom software, or does it just distribute the costs so much that it makes it easier to ignore the real problem?

If the customer is always right, does that mean that they are also responsible for what they ask for?

Or are there a lot of programmers who truly believe that the perfect general abstraction scheme is just over the next hill? Is it perhaps often the downfall of the intelligent that they become too comfortable with complexity and learn to court it for its own sake (and/or for simple historical and personal reasons), even when it is not necessary, or even detrimental?

Is software (or life for that matter) complex, or is it what we make of it?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Voting in this poll is easy, because there is no poll

Votes: 0
Results | Other Polls

Related Links
o Bram Cohen
o yes
o link
o programmer s
o lighten up
o right tool for the right job
o requiremen ts
o ø
o wned
o there is no spoon
o Chuck Moore
o everyone's favorite
o sacred cows
o other people's code
o Refactor
o refactor
o refactor [2]
o nut
o claims
o The Software Problem
o no silver bullet
o smart people
o Zen
o levitation
o mental
o reality
o software written for the large and complex - and thus poorly defined and understood - general case
o don't expect
o don't like
o real world
o someone
o distribute
o real problem
o the customer is always right
o responsibl e for what they ask for
o perfect
o general
o abstractio n
o scheme
o next
o hill
o complexity
o learn to court it for its own sake
o not necessary
o detrimenta l
o or life for that matter
o we make
o Also by Dont Fear The Reaper

Display: Sort:
HOW-TO: Be A Great Programmer And Win At Life | 52 comments (29 topical, 23 editorial, 0 hidden)
All nonsense (3.00 / 7) (#12)
by cronian on Wed Jun 29, 2005 at 12:05:13 AM EST

I think the truth of the matter is that the programmer actually has to pay attention, and work at it. The thing is that many programmers either intentionally or uninentionally don't really concentrate most of the time.

Furthermore, it is virtually impossible to tell whether a programmer is working at their full potential. So, there is no real way for the management to tell whether the programmers are actually working hard or not.

Many bugs are often harder to find than to fix. So, there is no easy way to tell how many errors the programmer made, and furthermore errors are expected. So, there isn't really any easy way to hold the programmer accountable for the bugs.

If a programmer actually works with their full concentration, and focuses on the project, it is much more likely to suceed. However, this doesn't make a good explanation.

Explanations need to sound fancy and impressive. So, when describing their methodology, they can say how they work to manage complexity by reducing everything to simple blocks like the building blocks of the great pyramids. However, they are really just describing that they were paying attention.

We perfect it; Congress kills it; They make it; We Import it; It must be anti-Americanism
The steps to succesX0rs (2.00 / 3) (#16)
by destroy all monsters on Wed Jun 29, 2005 at 07:48:39 AM EST

1. Get the NSA, or some other sucker agency to give you a massive government grant.

2. Build your near-sentient supercomputer and have it work out ways to pay you (preferably using that spiffy trick Richard Pryor perfected in Superman 3). Meanwhile scramble to get access codes to ICBM's.

3. Use your computer now named Colossus to blackmail teh world into slavery lest you unleash fiery hot nucular deth upon them.

4. Profit

You are teh winnar!  

"My opinion: You're gay, a troll, a gay troll, or in serious need of antidepressants." - horny smurf to Lemon Juice

This is a brilliant MLP. (2.85 / 7) (#24)
by it certainly is on Wed Jun 29, 2005 at 01:27:42 PM EST

The link to Joel's abstraction essay alone is enough to make me vote +1FP. I'm also a sucker for the Adequacy-style tangential linking scheme. Great article, thank you.

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.

hrmmm (2.50 / 2) (#25)
by khallow on Wed Jun 29, 2005 at 04:13:17 PM EST

Originally going to give the story +1 section, but I don't like the silly linking scheme. So 0 here. If it makes it, I will endeavor to persevere.

Stating the obvious since 1969.

SECRET TO GOOD PROGRAMMING. (2.37 / 8) (#28)
by tweetsybefore on Wed Jun 29, 2005 at 06:29:56 PM EST

To become a better programmer:
  • get alot experience writing programs
  • learn how to read programs (when you encounter problems try to trace through and understand as much code as possible especially libraries)
  • learn how to describe programs without a programming language.
  • write logical documentation(document primarily functions classes and data structures). If you are unsure how to do this look at javadoc this is excellent documentation or doxygen. Follow that format. Do not simply comment lines code, it is not really usefull, only comment lines of code if you are doing some non-trivial algorithm, if you can simply refer to the name of the algorithm do so.

    For Methodology:

  • Try out new things and do what works for you
  • Work with people you agree with.

    For a project:

  • Do it yourself for yourself.
  • Don't let people control your salary. Only take suggestions.
  • Actually care about what you are programming.
  • Show it off to other people and be proud of it.

    If you do all of the above you will succeed in programming something cool.

    I'm racist and I hate niggers.

    • Um, these two ideas just don't splice (2.50 / 4) (#29)
    by D Jade on Wed Jun 29, 2005 at 08:04:58 PM EST

    Be A Great Programmer And Win At Life

    In order to be a good programmer you have to have no life. In order to win at life, you need to be a spineless yuppie with a MBA and a porsche (or lame expen$ive car of choice)... Either that or you have to marry one.

    You could be a programmer who marries a spineless yuppie though... Dammit! I just disproved my own theory.

    You're a shitty troll, so stop pretending you have more of a life than a cool dude -- HollyHopDrive

    Dude (1.20 / 5) (#35)
    by ljj on Thu Jun 30, 2005 at 08:14:55 AM EST

    What are you on about?

    --
    ljj

    Bah (none / 0) (#38)
    by trhurler on Thu Jun 30, 2005 at 08:49:27 PM EST

    First of all, the idea of using simple software to create reliable solutions is not nutty. It is absolutely proven. In a million years, monolithic office suites will still be buggy, slow memory hogs that occasionally crash and destroy your data. On the other hand, loosely coupled systems of small, well tested modules are rapidly approaching the scale of the more integrated systems, and their reliability does not necessarily drop at all. The admonition never to reuse anything is stupid, but the admonition never to solve a problem you haven't been confronted with is dead on, and the idea that some grand abstraction is going to result in usable software that's tens of millions of lines long or more is just stupid. That software will always be buggy, inefficient, and generally crappy.

    Second, this article fucking sucks. The author's tone suggests "infantile wankstain."

    --
    'God dammit, your posts make me hard.' --LilDebbie
    Guy Kawasaki talk (none / 1) (#40)
    by mberteig on Thu Jun 30, 2005 at 11:22:44 PM EST

    I recently was emailed this link to a talk by Guy Kawasaki.  It's marginally related: software is one way to do something new, and at this point, most software development is still done to solve new problems.  Just more fodder for an MLP :-)


    Agile Advice - How and Why to Work Agile
    This puts the responsibility on the programer (none / 0) (#41)
    by lukme on Fri Jul 01, 2005 at 08:00:29 AM EST

    The fundamental problem is that the people who are specifying programs are not the ones using them, however they are the bosses of the people using them. Typically, they put in features that make managing their employees easier for them, not necessarily making their employees job easier.

    Most of the time, the programmer working on a project has a specification that is unimplementable and an aggressive deadline (read unrealistic deadline). Remember, the programmer is paid to write code and gobs of it - not to refactor or to reflect on the perfect architecture.

    The best projects that I have seen have started off small and simple and have grown with the user. This will be slower to develop than a waterfall lifecycle, however, the software gradually becomes more comples as the end user becomes more sophisticated.




    -----------------------------------
    It's awfully hard to fly with eagles when you're a turkey.
    uhh (none / 0) (#42)
    by trav on Fri Jul 01, 2005 at 12:00:02 PM EST

    So you're quoting a programmer that works only with his own code, designs his own programs, writes his own specs, has no deadlines, has no co-workers to deal with, no boss to report to and basically no requirements of any kind, on what it takes to be a great programmer?

    What?

    Programming is hard (none / 1) (#44)
    by vadim on Fri Jul 01, 2005 at 02:40:06 PM EST

    And programmers are lazy, have impatient bosses, and customers who don't understand what a programmer does, or technology at all.

    For instance, I work as a programmer. Today I was involved in another round of conversation with a co-worker who was very confused about what GPS is.

    He said things like that somebody gave him GPS software. We would protest that his PDA doesn't have any GPS hardware. He would counter "but it has bluetooth!", and we'd say "but that won't make it talk to the satellite!". We were about to order a GPS receiver, when he decided that loading map software into the PDA was good enough. Looks like he heard a lot about GPS and decided that what was needed in order to view maps.

    This is one of the main problems. We're swimming in thechnology, and there are lots of people who still don't understand lots of it. Then the programmer is the one who gets charged with an impossible or incorrectly specified task.

    People also hurry too much for their own good. I'd like to rewrite some really ugly parts in the application I maintain (wasn't written by me), but it'd be rather hard to explain what exactly I've been up to during a whole month when I proudly announce the next version is ready, and it looks identical.
    --
    <@chani> I *cannot* remember names. but I did memorize 214 digits of pi once.

    You know (none / 0) (#50)
    by creature on Sun Jul 03, 2005 at 12:11:58 PM EST

    For a how-to article, you ask a lot of questions that never get answered.

    HOW-TO: Be A Great Programmer And Win At Life | 52 comments (29 topical, 23 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!