• hashim (unregistered)

    even your article is boring.

  • Robert666 (unregistered)

    A UI generated from the database is just as bad as the database that’s generated from the UI.

    Absolutely not. Generating the UI from the schema (which includes all of the catalog, i.e. constraints) is the only way to enforce 'one fact, one place, one time', or as the OO folk call it 'don't repeat yourself'. Don't repeat.

    The argument is that database (relational) schemas are too often un-normalized, and therefore can't be complete with regard to constraints, i.e. some constraints are 'too complicated' for the database. Wrong. The data is what persists. Since 2000, how many languages du jour have there been? How many frameworks for web development? The SQL (not really relational, but close enough for government work) database allows data to persist across databases and time. I know, folks complain that each vendor's SQL is different. And at the margins, yes. But no one said you need to schema at the margins. Your argument to KISS applies to using SQL, too.

    Beyond that, there are programs like SwisSql, which are able to translate most SQL across databases, if one needs to.

    A normalized database's purpose is to generate new data from existing data; that's the whole point. Constructing input screens from the schema drives the screens to be data logical. In doing so, designers and users find where the potholes are. That is a good thing. Or put another way: if you CAN'T generate a useful UI from your catalog, your data model is screwed. Think about that for a second. Go back to your premise of tedium and repellence of complexity. How the UI LOOKS is separate and apart from the data being displayed. Whether it's a list box or radio set or foobar is programmable. Whether an input field is dependent on some other data for validation is in the catalog. If it isn't, your database is screwed.

    And so on.

  • John Cowan (unregistered)

    The essence of a profession, as distinct from a job, is that a professional is answerable to two masters: his client and his peers, and has to balance off their demands. Those peers set up all sorts of rules that professionals have to abide by. A doctor that cut off a patient's leg just because the patient asked him to would have trouble, and still more a lawyer that helps his client cheat on his taxes (as opposed to helping him find the best legal way to reduce them).

    That said, I don't know if programming (I am old-school, and disdain such inflated expressions as "software engineering") is a profession or not.

  • Some Dude (unregistered)

    Excellent. Well, here's a list of realizations that complement your article.

    First, programming is work, it's laying and connecting pipe. It's not clever. It's not glamorous. Any satisfaction you get from doing it is the satisfaction of having gotten something done, and not because you're somehow special for having done it. There's no Zen to it, unless it's in the acknowledgment that all is work and all is boring. Don't take the intimidation people feel who don't understand it to mean it requires intelligence or that you're special. Stop trying too hard. Nobody's impressed. Nobody's paying attention. And if they are, it's probably because you look funny or you have broccoli in your teeth.

    Second, programming is organization, and most of the time, trivial organization. Put stuff here, put stuff there, move some stuff around. Tada, there you go. Sometimes it feels like cleaning your bathroom, or organizing your bookshelf.

    Third, reasoning is just a mechanical process. It's not magical, it's not particularly fascinating, per se. It's completely described by the syllogism. What do you think proofs are? They're descriptions of how you reasoned from A to B. Computers can do it. What they fail in is conception and judgment.

    Fourth, people who fail to acknowledge this reality about programming, while they believe they are themselves somehow super smart, are probably people who lack creativity, intelligence and imagination, or are somehow short-sighted, much like a dog running after a chew toy with the same enthusiasm day in and day out. Maybe you are dumb. The least you could do is be honest and quit being a geek. You also probably lack social skills, and no amount of rapture is going to save you from the self-inflicted and boring cookie-cutter life you're leading and will continue to lead. There's nothing more irritating than listening to some guy who's so caught up in his own trivial self like some adolescent turd. Nobody cares if you wrote some "killer app" or that you know some terminology. Again, no one is impressed, and you're not special.

    Fifth, look at the big picture. Getting lost in irrelevant details not only makes you look stupid, it makes you stupid. It also causes your balls to shrink. This applies to any fixation that provides you with a faulty sense of self-worth. Programming is a trade. People need code to do other things. You write it.

    Sixth, "the zone" is not a moment of supreme intelligence and insight. No. It's a moment when your brain shuts off enough that it stops protesting and thinking about more interesting things (like sex) and allows you to focus on doing something boring like moving code around in an editor. Personally, I find it a relaxing activity. Short cuts to "the zone" include alcohol and weed.

    Seventh, all code sucks. And as this article states, the more clever you try to be, the more you try to compensate for a small wiener or keep yourself from the realization that coding is a chore, the worse the code is. Get over your code ego.

    In summary, good programmers acknowledge that there is no magic to programming. They just have the self-discipline to work through the problem and don't feel the need to prove themselves to anybody. They aren't looking for something in the act of programming which isn't there, like some Don Quixote with Down's. Nobody cares about you. They care about the product. Throw away all the bullshit life lessons they taught you at school or you heard from Big Bird or Oprah. Life is not a maniacal high on ecstasy. It an anticlimactic journey which always ends in death and where clamoring for more than just existing is just a waste of energy. That, and you'll end up irritating everyone around you and looking really awkward. Stop it or we will ignore you.

    To mangle a quote from Edison, programming is 99% perspiration and 1% not being a dumbass and getting back to perspiring.

  • Mahesh (unregistered)

    Couldn't agree more..sob sob

  • 101010 (unregistered) in reply to Starbuck

    she might if you aren't a dork. just don't talk too much about your l33t programming skills.

  • LongTimeNerd (unregistered) in reply to Uncle Bob Martin

    This sort of interplays with your Jocks vs Nerds. The reason nerds love programming is because they learn from the time they were small that having no looks, no social skills, and so no ability to get laid, never mind control the random chaos of existence in society, programming gives them serious relief as they are in total control of their environment. Its predictable and can even, apparently, be sexy, although I think its somewhat vicarious.

    Being long in the tooth, I truly enjoy the fact that hi tech nerds have replaced doctors and lawyers as the targets of attention in bars. Money still talks.

  • Iain Collins (unregistered) in reply to Max
    max:
    Don't write articles like this. You've just told us that:
    1. You don't have any experience in modern, agile development. <snip!>

    Because environments that are not more-agile-than-thou are old fashioned and are therefore inferior?

    You know I think you just might be the target audience for this article...

  • Iain Collins (unregistered) in reply to Miklos Hollender

    Miklos Hollender:

    I don't disagree with this article but I do take your point. However I think you are thinking of the types of cases you work with but perhaps neglecting other environments which call for different approaches.

    Personally, I find that most systems I work on is either so simple enterprise abstraction packages only makes it more complex and using a nice generic (abstracting) SQL interface library is more sensible, or so complex and ad-hoc none of the off the shelf solutions would do (at least without either being far too slow or again or adding horrible complexity and slowing down development).

    I would argue in practice is more common that not, and that is what Alex is driving at, but your right in that it can be much simpler and there are lots of even very cheap solutions to do just this kind of abstraction in particular for .NET and Java (but would note in some scripting languages it's so easy this sort of thing is redundant anyway).

    I do fully appreciate there are many types of app development where they completely rock and make perfect sense. I think it comes down to application type and business environment as to what makes the most sense, in some environments (by which I mean both technical and commercial) it actually makes less sense.

    As a general rule, I think developers from different environments often misunderstand each other because they are trying to apply their own hammers to others nails (and I'm not excluding myself from that). It's easy to think some other guys are "doing it wrong" because they are doing something in a way we personally dislike and would never want to be apart of (for perfectly good reasons) but that doesn't mean it's wrong for them.

  • Mitch (unregistered)

    Freakin' awesome article. I'm not even a programmer and I thought it was sweet. Thanks for the nice read.

  • alwin (unregistered) in reply to AC
    What's with all the hard coded values in the example of what code *should*?? look like?

    if (stateCode == "AZ" || stateCode == "TX")...

    So the next new state that adds this requirement means you have to recompile & redeploy all your code rather than just updating the data in a table.

    Not a good example for the young'uns.

    Yeah, you're right, it's bad. Adding a sql database, tables to contain the data, writing db connection classes, and a settings object which should be updated if the data is updated in the db via a trigger should make everything a lot easier.

    I'll pick "bad" compact code over complex fragmented code any day.

  • (cs)

    I remember reading the article the day it got posted almost a year ago and I was thinking, man is this guy right or what!?

    I was clearly in a situation where the drive and spark of the project and its team members had long run out and the grind had begun. It really made me re think my whole situation and I decided that I was not going to work like that. A year later I have joined a crack team of developers who put great honour in the software we deliver and we pride ourselves on being up to date on most current technologies, viable for line of business applications of course. And there really is a market for up 2 date new kids on the block out there.

    My problem at my previous engagement was that thejoy of knowledge and exploration were non-existing with my colleagues. I guess they had settled in life or something. I had not.

    I guess what I'm trying to say is that your dayjob don't have to suck, even if you're a programmer! If you're knowledgeable and brilliant there are plenty of companies waiting to hire you. Remember they should be glad you decide to work for them, not the other way around.

    I'm forward to some more life-changing articles Alex, thanks for the inspiration this article gave me.

  • Matthias (unregistered)

    You don't know what you want ! On one hand that's hard, but on the other hand, that's too easy... That's YOU is sucking.

    Program in Delphi, so ! Or C++...

    Programming is USEFUL (but boring and annoying... I admite...) But without this, NO programming means NO programs an NO OS... So no computer science!

  • Neil (unregistered)

    That is why I liked games programming (no specs, no documentation, no other programmers to mess up the code). Each game was a different set of challenges, puzzle game, 3d isometric fighting game, vertical scrolling shoot 'em up, flight simulator, racing game and a 16 week development schedule for 100% assembly language game :)

    I've also had to write custom software to convert 68000 assembly language to C++ which was a whole different set of problems.

  • Nightfly (unregistered)

    Amen.

  • (cs)

    A few years ago, a friend of mine suggested that User Experience was the new "sexy" tech position. At the time, I thought she was confused...UX didn't seem like a real tech position to me. After a couple years of study however, I found myself arriving at the same conclusion. UX is "sexy" because it's all about design and engineering and less about programming for the sake of programming. It's like stepping into the shoes of Leonardo da Vinci and coming up with amazing things to create. The programming part is just the act of making UX.

  • BushIdo (unregistered) in reply to hatterson

    The "balancing the extremes" is exactly why general advice articles are often not very useful.

    You use one userdefine variable, do some UI to make it really nicely accessable and all - and no one ever needs to change ist.

    You hardecode exactly to specs and just when you are finshed the boss demands this little extra, which doesn't fit at all in the model you devised.

  • James (unregistered) in reply to Proxima

    So true. And actually, a big reason programming often gets tedious is because people lose sight of keeping things straightforward. How many times do people code themselves into messes trying to make things "simple" (simple in the wrong way) and end up having to do tedious debugging to get their own monster to work. It's the whole "complex vs. complicated" thing. Small and smart is nice for a moment while everything is in your head, then becomes a cloudy box you have to strain to look into. I'd rather look into a big clear box that I can understand instantly.

    That's why I think it's silly when people talk about the verbosity of some languages (particularly Java) and say that makes writing code in those languages take longer, as if typing is all there is to programming. By that logic, the best speed chess player in the world would be the person with the fastest hands. This is not to say Java is a more productive language than others, I actually prefer Python, but not because it's faster to type, because it's faster to read.

  • Felix (unregistered)

    Although you sure ARE making some points, I think it's a little bit simplified.

    Of course, as a coder, you should most of the time focus on the business needs and nothing else, but what are those business needs? I know enough "legacy apps" that perfectly match the business needs that were identified and specified back then (last year), but are practically unmaintainable when it comes to changing even the simplest things...

    So, I think it IS crucial for a good developer to at least reflect the business needs himself, understand possible future changes early, talk to the customer about that, maybe explain some technical issues. And more often than not, this will lead to some software design beyond "if (a) then (b) fi" ...

    If you don't do anything more than creating code for the business needs that have been specified -- you are just that: a coder. Better try to be a developer :)

    And no, I'm NOT advocating horrible over-engineering, I just want to make clear that SOME engineering is needed most of the time, and it should start with understanding the business needs and examining that for "forseeable" future changes.

  • Ted (unregistered) in reply to Frustrated
    Frustrated:
    5. Tedium is Inescapable. No O/R-mapper or code-generator can ever solve the fact that records, fields, validators, etc. need to be defined, by hand, in at least two places (front- and back-end). A UI generated from the database is just as bad as the database that’s generated from the UI.

    And if you have a UI generated from the database, and a database generated from the UI, you end up with Filemaker

    Yeah, but according to Alex's logic, that is what you want: focus on the business rules and let FileMaker handle everything else.

    And, off topic, I have seen some exciting stuff built in FileMaker. http://innerfile.com/services/filemaker/consulting/

  • The great Nick (unregistered)

    Learn Off The Job, no i disagree it is the responsibility to offer you as much training as you need to do your job. When you train at home you are basically working unpaid. And I have a policy of no free work under no condition what so ever and it has served me well.

  • someone (unregistered)

    The best programmers ARE the ones who create the most beautifully-elegant, exceedingly-innovative code, AND the ones who can deliver software before deadlines, and under budget.

  • someone (unregistered)

    Junior developers enjoy introducing an unnecessary complexity such as any-cool-library-floating-around simply to learn how to use it. Senior developers enjoy working less and getting more done, which means they don't enjoy adding any unnecessary complexity. It's hard to be a team when someone too senior has to work with someone too junior. :) I'd vote for senior-only companies.

  • (cs) in reply to Sucks
    Sucks:
    This article sucks.

    Good job. You've highlighted the problem and then said "Suck it up and act like the tool you are."

    Way to think inside the box, Alex.

    The majority of the time, thinking inside the box is the way to go.

  • (cs)
    Alan M. Turing:
    Instruction tables will have to be made up by mathematicians with computing experience and perhaps a certain puzzle solving ability. There will probably be a great deal of work of this kind to be done, for every known process has got to be translated into instruction table form at some stage. … This process of constructing instruction tables should be very fascinating. There need be no real danger of it ever becoming a drudge, for any processes that are quite mechanical may be turned over to the machine itself.
  • Andrew Gibson (unregistered)

    I would like to add my voice to the "if you aren't having a great time, you're doing it wrong contingent." Boring software is dangerous.

  • Andrey (unregistered)

    I understand your point, but imagine how boring other professions(except several) are (or at least seem to be)...

  • Rohit (unregistered)

    If you find it boring - at work and at a hobby, do something else! I was a software developer for 7 years writing banking software. I tried very hard to cultivate a passion for it, by coding at home etc, but I just couldn't. So I quit and became a math and sports teacher, which I find much more enjoyable.

    Programming can be fun, but I guess it depends on the individual. I know lots of folk at my old place of work who love their job and are very passionate about it. I just couldn't do it!

    christmas++!!

  • DOKKA (unregistered)

    Another important fact is that most programmers aren't even professional. they don't know enough of the language to even do things properly. This is the current reason why I hate the field. It's as if you play the janitor and the architect, and doing both is insanity.

  • ayeeee (unregistered) in reply to Starbuck
    Starbuck:
    The real WTF is calling yourself a "rockstar" if you are some l33t c0dEr. I don't care how "sexy" your programming skillz are, that hot chick in HR isn't going to sleep with you.
  • jonny (unregistered)

    you find that boring?

    try going the whole day passing parameters to dull functions and making unberably long associations to arrays for god knows why?

    I talking abou ERP software, how those are boring

Leave a comment on “Programming Sucks! Or At Least, It Ought To ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article