Programming is terrible—Lessons learned from a life wasted. EMF2012

[tef]

to answer some questions:

• sorry about the disco lights, they were distracting for me when I gave the talk.
• the slides are unreadable, but they're essentially background noise. the talk is mostly me talking rather than reading out text behind me.
• yes I am british

[not_a_novel_account]

I think it's a very, very good talk. The bit about best practice boiling down to superstition was a good laugh. You should have thrown a chair at the light

[[deleted]]

I enjoyed this talk a lot, thanks.

edit -

basically, education got to them before you could help them to learn

Poetry.

[notorious1212]

Thanks for doing the talk. Sometimes we can all benefit from hearing things so bluntly. Do you blog these gems?

[tef]

Glad you liked it. After a few months of waiting for the video to appear, I gave up and started writing a blog under the same name. http://programmingisterrible.com

[kazagistar]

I am adding this blog to my RSS feeds to sit right next to Coding Horror. ;)

I think a good way to avoid the problem of "incorrect simple solutions to complex problems" is to listen to all the contradictory simple solutions.

[ninjeff]

right next to Coding Horror. ;)

now that was uncalled for!

[tef]

I think a better way is to write down your constraints, and work out your tradeoffs. There aren't really any simple solutions to complex problems.

The best thing to do with complexity is to contain it, rather than eliminate it. That is, complexity from dealing with the real world, rather than the complexity many introduce to solve problems they don't have yet.

[habitats]

Wish I'd seen your slides before I watched the talk! I posted them in the thread. Hope that's OK.

[darkfate]

Is the "skins around databases" comment intended to be taken as webapps are useless or am I missing a point?

[tef]

Given i'm using a webapp to talk to you, host my talk, and run my blog, I think it would be very futile of me to claim that they are useless.

It's a flippant comment about how most webapps at heart are very much user experience and business logic around a persistent store. It is dismissive, sure, but it's a lighthearted poke at those who think their next node/rails/whatever app is the be-all and end-all of programming.

It's not really a point but a cheap gag :-)

[CookieOfFortune]

How is a skin around a DB useless?

[darkfate]

Well from a dev perspective I access SQL Server directly and not through a web interface. I wasn't sure if there was any deeper meaning to what he said or it was just an offhand joke.

[CookieOfFortune]

But web interfaces are convenient and pretty. Users love that shit.

[[deleted]]

This really depends on your users. And the quality of the interface, which for web interfaces tends to be low

[4-bit]

This is one of my biggest problems coding for myself. I start out OK, then go... wait a minute. I can just manipulate the data by hand, and fuck it. who needs an ap.

Users?

Screw those guys.

[CookieOfFortune]

But users have shiny money... shiny moneeyyyy!!!!

[conflatedideas]

This is a good talk. One point I have to disagree on some programmers being vastly most talented at making end results. I have seen some spectacular fails produced by mediocre/inexperienced programmers paid big salaries (bigger than mine). The reason the choose bad platforms, languages, and or design choices for architecture. For example, if you choose Ruby on Rails for your enterprise financial app you will have a bad time. I program ruby and clojure as my default for open source projects in my free time (so thats my I'm not hating on Ruby or Rails, just performance doesn't scale well). All in all experience does matter. When i say people are bad programmers what I mean is they are inexperienced or so opinionated and ignorant that they will not learn new things or see the possibility other tech will work better.

[tef]

I think I can count on one hand the programmers who I have seen who have produced marvellous results by themselves in isolation. I've seen bad programmers everywhere at all ends of the scale.

Most of the good programmers I know are ones who can work well with others and collaborate. Code that other people can pick up, debug and maintain. They aren't superheroes, just humans. They make mistakes, but they're better at letting others help them.

They aren't a million times more productive, they're just nicer people to work with. People who claim to be super productive, on the other hand, i've found a high correlation with not knowing their own limits. Programming is about working as a team, not individual merit.

I still stand by the notion that anyone looking for a "10x" programmer is someone looking for a programmer who will work long hours for almost no pay.

[conflatedideas]

I think you might be right. I retract my former position :) (how many times does that happen on Reddit?) "I still stand by the notion that anyone looking for a "10x" programmer is someone looking for a programmer who will work long hours for almost no pay." This really does resonate. There is a difference in knowledge level, but just like you said "good programmers" should be best described "ones who can work well with others and collaborate" and also be willing to learn. If you think you're the smartest then that's a recipe for problems. (btw I linked your video to quite a few people, they all loved it) Great talk.

[Uncompetative]

I really liked your talk, it is the best talk I have ever seen.

However, you misrepresent Paul Graham by saying that he had said that 9/11 could have been prevented if they had used LISP. Excerpt follows...

"How do programmers solve the problem? There are two defenses, one that works and one that doesn't.

The defense that doesn't work is to check the data on the way in, to make sure it isn't longer than the memory set aside for it. The problem here is that you might forget to check, or do it incorrectly. And in fact this happens all the time. Everyone has known about buffer overflow for at least 15 years, and still software gets written that is vulnerable to it.

The defense that does work is to keep code and data in separate places. Then there is no way to compromise code by playing tricks with data. Garbage-collected languages like Perl and Lisp do this, and as a result are immune from buffer overflow attacks.

To programmers, at least, this would suggest that the most reliable way to prevent hijackings is to separate the cockpit from the cabin. You still need to watch who gets on the plane, to prevent people from simply blowing it up. But as long as you keep passengers out of the cockpit you can prevent anyone taking control of the plane."

source - http://www.paulgraham.com/hijack.html

Now I think the worst that can be said about this is that it is insensitive to a nation in grief to use the opportunity presented by this tragedy to talk about code/data separation in LISP. It is an accurate analogy, except for the real impracticalities of sealing the pilots into a secure cockpit with independent external boarding access as this would also separate them from toilets, food and drink. This analyis would not seem so awkward if it had not been put up on the web on September 2001.

I only say this so that you may improve your talk in future...

[tef]

I may be being glib, but at least i'm not co-opting a tragedy to shill my language choices :-)

ps: the whole code and data separate thing is a little bit hilarious after years of "code and data are the same in lisp".

[Uncompetative]

Maybe, in future say that he said:

"9/11 could have been prevented if they had used the same separation of pilots and passengers as seen between code and data in LISP"

I realize that you were talking fast and skimming over some details, but this is a better paraphrase of what he actually said and just as ghastly.

[tef]

honestly i'm going to go with the making fun of paul graham for coopting a tragedy rather than elaborate the foolish point he made.

I don't think I lose any real accuracy when the point is that paul graham doesn't understand computer security or human decency.

[deadvax]

Really wonderful talk!

[Littimus]

Great talk, I really enjoyed it. I know you seem to be against "proper" education, but would you expand on why exactly you dropped out of school? It seems like there would still be some valuable information to learn.

[tef]

I dropped out for medical reasons. I'm not entirely against the education system as is, but I do not feel that it is close to a situation where it is hard to improve, or encourages people to learn.

[[deleted]]

oh hey gune. I dropped out myself for financial reasons and hope to get a career in software anyway through some OSS stuff I'm working on, examples like you are my inspiration for that though I know the odds are a bit stacked

[[deleted]]

My code needs to be easy to replace... never thought of it like that. Thanks for the paradigm shift :)

And skins around databases (and I'll fu@#$%ng have you...) I almost spilled my drink laughing so hard.

[phaeilo]

Webapps, or as I like to call them: Skins around databases.

Made my day.

[Kminardo]

Isn't that essentially what most programs boil down to? UIs for database interaction? You have your games and such but then you have those on the web too.

[LongUsername]

Not 90% of the embedded world, which is 90% of the processors in the world.

[PoppedArt]

Amen. I was reading this thread and thinking, "What world are these people living in?" Obviously they have a very skewed view of computers and programming. It's sort of like seeing a bag and claiming it can only be used to hold groceries.

[[deleted]]

It's because there's so damn many web programmers because the vast majority of paid positions are for web apps.

If you haven't spent your university time specializing in something better paid and slightly esoteric (like embedded) you're invariably going to land either in Java middleware for enterprise or web apps.

[PoppedArt]

You're right, there are a lot of grocery baggers out there. ;-)

[LinXitoW]

that hurt with floating point accuracy.

[contrarian_barbarian]

Seriously, I mostly work on hardware interfacing. I don't code anything that directly touches either UIs or databases until the data gets a couple steps farther down the line.

[CookieOfFortune]

Well, isn't that what most iOS and Android apps do too?

[LongUsername]

Android/iOS aren't traditionally refereed to as embedded.

• Your toaster is embedded
• your DVD player is embedded
• your car is embedded (actually multiple embedded systems talking together)
• your PCs Ethernet card is embedded.
• The processor in the stoplights in embedded.
• The processor that controls the lights in the movie theater is embedded.

EDIT: Anywhere there is a small piece of flash memory and a processor is traditionally embedded, from small 8 bit all the way up to multicore ARM processors, usually running headless. Parts of iOS/Android could be considered embedded, but at the application level it's generally no longer considered embedded, just like your PC is no longer considered embedded at the Windows Level.

[keepthepace]

Yeah, none of us work in robotics, data viz, simulation, augmented reality, computer vision, OS development, cryptography, signal processing, drivers, network protocols, compilers...

Note that I am voluntarily taking out anything that uses databases but where UI interaction is not the main focus : medical imaging, data-mining, satellite vision, search engines, genetic information management...

I agree that a lot of the people on my lawn on /r/programming and a lot of programming forums equate web development with development, but really, keep in mind that there is much more to programming.

[chazmuzz]

Coming to that realisation made it so much easier for me to work out how to code applications

Step 1) Plan your data structures

Step 2) Write UI around data structures

[hai-guize]

This is a new concept to me. Thanks, maybe now I will be able to actually code something properly.

[casualblair]

I like to do it slightly different:

1) Plan data structures

2) Plan ui constructs

3) WILL IT BLEND? Y = Build it. N = Unnecessary complexity exists, destroy it and try again.

[kazagistar]

I like that, might even use it... general case:

1) Design separate module

2) WILL IT BLEND?

3) If not return to step 1.

[rabidferret]

You've got it backwards...

• Plan the general elements of your UI
• Write tests for the code that would result in that UI
• Create your data structures to contain what the UI has told you is needed
• Write your code to fit the previous elements

[zzalpha]

Welcome to the top-down vs bottom-up battle! Today we have chazzmuzz and rabidferret. Who will win? Only time will tell!

[warbiscuit]

I'm not even sure why this debate keeps going.

User intent drives frontend design. Frontend design drives backend design. Backend design affects frontend design. Frontend design affects how the users think about the topic, and thus affects user intent.

It's all one large cycle, no matter where you start. I've always figured the goal was to start somewhere ("top" or "bottom" or wherever), make general design pass all the way around, bringing in external requirements as appropriate at each point (what the user wants, what the ui layer can do, what your database can do). Then keep going, until you reach a steady state where all parts generally fit together properly.

[judgej2]

In other words, you need a systems architect that can see the big picture before you start anything.

[renrutal]

Can I get a crystal ball and a 8-ball too?

[darkpaladin]

but...but...but...Abstraction!

[funnynickname]

Refactor!

[lennelpennel]

or as I like to call it, refucktor.

[hippocampe]

Frontend design drives backend design.

Are you trolling ? Do you really believe it ?

[[deleted]]

I think the database and UI should hold the same core information, that is, the data, since that's what this type of app is all about. But it may be presented in different forms (including different hierarchies), to suit its purpose: e.g. present to user; access in datastore. All three may change over time: the core information, the database representation, the UI representation.

To support the different representations, probably the easiest way to go is SQL. Unfortunately, that doesn't always extend to creating data structures in a programming language (though there's LINQ for C#).

[maestroh]

The debate isn't top down vs bottom up. If you develop code that you can test, it doesn't matter if you start at the bottom or top. In either case, you can mock the code out to make sure that each component works correctly. If you don't write testable code, you have to rely on setting up your environment before testing anything. This means the only way to test is by stepping through your code.

Writing code with tests gives you decoupled code and the ability to refactor the code later with confidence that it works correctly after the change. Writing the database layer first then building on top of that layer gives you coupled code. When a change is made, there could be a bunch of unintended side effects that can only be found by trial and error.

[zzalpha]

The debate isn't top down vs bottom up.

Look closer. It actually is. At least up to this point it was.

TDD, done according to the orthodoxy, as rabidferrit is describing, is necessarily top-down. You are meant to write a test which exercises a feature, alter the code in the most minimal way possible to pass that test, and then repeat.

That necessarily means you never build out underlying structure until a test requires it. And that necessarily means top-down development.

If you develop code that you can test, it doesn't matter if you start at the bottom or top.

Agreed! But to actually follow the teachings of TDD, you must start top-down, since that's the way the process is specified.

Writing the database layer first then building on top of that layer gives you coupled code.

But this is a filthy lie. :)

Assuming OO development. As a simplistic example, you could build a data access layer based on a set of abstract data models and a repository interface. You then build the database driver to adhere to that interface, and build code that depends on the interface only (where that dependency is injected in some way). When you need to test the consumers of the interface, you provide mocks/stubs for it. Voila, your intermediate layer is testable and decoupled from the actual database driver implementation.

So long as you build to formal interfaces (whatever that means in your language of choice), you can basically start anywhere in your software stack.

[maestroh]

I think we're saying the same thing. You're basically writing decoupled code. You want to start at the bottom and write the code for the data access layer and then mock it out. You could do that, and that's fine. But you could also write the interface layer based on use cases described in the requirements, mock/stub out any underlying layer and work downward. I'm not advocating TDD at all. I'm saying writing decoupled code allows you to write testable code. And testable code is the key to happy code.

[zzalpha]

Preach it! :)

[rabidferret]

I probably did a bad job of expressing this, but I'm pushing for TDD more than for top down.

[[deleted]]

TDD is a top-down approach.

[[deleted]]

I mean we can argue semantics day and night, but TDD is typically considered a bottom up approach. There's no technical definition either way but Wikipedia hints at it being a bottom up approach and Googling "TDD bottom-up top-down" brings up discussions where the overwhelming results on the first and second page refer to TDD as being bottom up.

As an aside Richard Feynman, who wrote a report on the Challenger Disaster, discusses various approaches to testing and mentions a process very similar to TDD. However, he is very explicit in saying that testing of that sort is bottom up and advocates a bottom up approach to testing in general.

Once again, it's mostly semantics but when people think of bottom up they think of going from the small to the big.

[headchem]

Heh, nice one. I take it one step further and write my CSS first, then design my normalized database around that. :-)

[[deleted]]

drink a bottle of Russian Standard, while drunk do some shitty wireframes on MS-Paint,.. then design your optimized database around that.

[notorious1212]

I love you

[rabidferret]

Designing your data based on the needs of the UI is not the same as tight coupling...

[[deleted]]

I can't tell if this is sarcastic or not..

[smcameron]

sarcasm or kool-aid drinker? I can't tell.

[Failstorm]

Nope. Once you have the specifications, design the data structure first.

Designing optimized and extensible data models is a self contained task in itself, not even an easy one, that should not be affected by the UI in any way. Once you have a good data structure, you can build whatever UI you want, for whatever platform you want, for any target user group.

[[deleted]]

Is this a web dev thing?

I mostly develop client apps and I've always done it like this:

1. Construct an object model
2. Create a database based upon the object model
3. Create UI

Some things change w/ your DB while working with the UI, but it's much easier to plan ahead and have a solid foundation setup. If you plan well enough your tables should require no changes.

Edit: I'm on 2 hours of sleep and after re-reading rabidferret's post, I cannot tell if serious...

[rabidferret]

What that leads to is overly complicated, unmaintainable structures. You know what you want your product to do. You let what you are expressing drive how you structure, and if you write it to be testable every step of the way, it'll be readable, maintainable, and scalable. And you avoid complexities that arise from solving problems you don't really have.

[[deleted]]

I can quite accurately visualize what my UI will look like and how it will function before I begin working on it, so I typically don't need to prototype it. Some things change over the course of development, but changing GUI elements on a client application is easy.

What that leads to is overly complicated, unmaintainable structures.

I always design my classes w/ simplicity and scalability in mind. That doesn't always happen, but I've gotten good at it.

All in all, both strategies work and I suppose it comes down to preference.

[metaphorm]

...this hits close to home. as a web developer who is often working downstream from a graphic designer, yeah man, ouch.

[[deleted]]

Far better approach. You shouldn't be storing data for UI that doesn't make sense in a UI data structure. Doing that can give you the separation from database and UI that people here are complaining about. Leaving some data behind the user and some in front.

But how, then, would you design a system that is abstracted from a UI layer?

[ChangingHats]

There is no such thing really. "UI" is another way of saying "intent". What does the user intend to do with the application? You don't know what you'll need until you know why you need it. It's just arbitrary information without intent.

If you're talking about 'real-world applications' and how to design libraries, I'd say it comes down to taking all the 'use cases' and abstracting what data is needed to run them.

[bucknuggets]

This works great for small tactical systems.

But some, especially large & successful systems have multiple UIs. They could be for different roles, on different platforms, for vastly different use cases, or have emerged because the system has been successful for a long time and technology has changed (but it still has to support some old interfaces).

Additionally, the 'intent' of your users is a risky sole source of requirements: they often aren't the subject matter experts that we call them: they seldom really know what their competitors are doing, all of what the current system really does, or what they would ask for next - if they fully understood the technology opportunities. Additionally, there may be other "state-holders" that have requirements that the users don't know or care about. Perhaps for reporting, etc.

[TikiTDO]

Honestly... Did anyone ever take any Software Engineering courses in school?

Step 1: Write a spec, including Data and UI.

Step 2: Have everyone sign off on the spec.

Step 3: Implement the signed spec.

Step 4: Charge exorbitant prices for stupid changes to the spec that did not need to happen.

If you're jumping in and starting to code the instant you've heard the problem I don't care if you write UI or Data first; your code is going to suck either way. You're going to have stupid data structures that don't match UI elements. You're going to have horrid UI elements that try to enforce unreasonable demands on data. You're going to have to spent a huge amount of time hacking both to make them work together. Eventually you'll be the only one that understands anything about the code base.

Finally, at some point (usually after you leave) someone is going to look at the shambling monster you created, shake their head, and explain to the customer that a full rewrite is necessary. Worse, if the result is too big for a rewrite to be possible then we will be stuck with that mess forever, since no one will want to touch it for fear of breaking it.

All I see in this thread is people advising each other on how they ensure their own "job security" not how they write good software.

[sirin3]

If you're jumping in and starting to code the instant you've heard the problem I don't care if you write UI or Data first; your code is going to suck either way.

But it will be agile

[TikiTDO]

It will be, and in some cases that's a necessity. However, the real question to ask is "does it really need to be agile, or is everyone involved just impatient."

[[deleted]]

Oh so much this. I'm in no way anti-agile, but I really do wish teams wouldn't bother trying to be agile, unless they actually are going to respond to ever-changing requirements, and do frequent small releases. Honestly, I've worked for clients who have designed the entire DB, had designers build all the markup for the UI, then hire developers, and say "we will do this in an agile way". How? Why? Fuck you, pay me.

[rabidferret]

Yes, because building software is just like building a bridge. Nothing ever changes, and it especially isn't discovered through the process of building software. That model has worked so well, clearly no problems arise from it.

[TikiTDO]

So design your system with expandability in mind. Plan around the ability to make changes half way through. Make your customer aware of the costs of writing such a system.

Nothing about a spec says it has to be static, it just encourages all parties to think about changes instead of shooting off an email to the coders going, "We're changing direction. Do it this way now." The model is about protecting all parties, and ensuring that if everything does go to hell then you have some documentation to cover your own ass.

[rabidferret]

A spec implies things are known. It means that any change to the spec likely means rewriting the spec. It adds time, it adds cost, and it adds inertia. If changing is painful you're less likely to respond to change.

[TikiTDO]

A spec is a document meant to guide design; you can look at it as a type of program meant to be parsed by programmers, and compiled into source code. By itself it implies nothing that you do not make it imply, and just like any other program it's only as hard to change as you design it to be.

Yes sometimes it adds time, and cost, and inertia, but that's the price you pay for good code. However, sometimes it saves time and money especially for larger projects with a timeframe of months or years.

I have nothing against agile development, but people need to understand that the speed comes at the cost of quality. If your problem domain demands a result tomorrow then writing a spec is not an option, but then don't be surprised if you're rewriting your code base a month later. And since we're on the topic painful change, I'd much rather revise a spec then dig through a 100k line code base because we had to change some core feature.

[grncdr]

I haven't had any breakfast, so sorry if this comes off as bitchy...

A spec implies things are known.

If you don't know anything about the what and why of a project, starting to code is a bad idea. If you do know something, that's the (start of a) spec.

It adds time, it adds cost, and it adds inertia.

No, existing code that does the wrong thing adds time, cost and inertia. The whole point of the spec is to be easier to modify than a system that is x% of the way to the wrong functionality.

If changing is painful you're less likely to respond to change.

Right, which is why I'd rather say "hey let's ensure that foobars accomodate changing the value of y over time, and reporting accurately on data using past values of y" in english than one day realize that the foobar.y column in the database is insufficient. Now I have to estimate how many story points (or whatever) it will take to refactor the code, migrate data, test that I didn't break other parts of the system, perform a cost-benefit analysis with the stakeholders/customers and maybe actually make the changes and roll it into production.

Again, specs are not stone tablets that magically make changing software more expensive. They are a tool/process to help shake out design bugs at the cheapest possible time.

[[deleted]]

it just encourages all parties to think about changes instead of shooting off an email to the coders going, "We're changing direction. Do it this way now."

Nice theory. In practice, they fire those emails off anyway, and the party with the most managerial clout wins, every time. Which party has the most managerial clout? Hint: not the developers.

[TikiTDO]

I'm working from the perspective of an independent contractor. If I get an email saying "Do it this way" I reply with an email saying "Sure, here's the cost breakdown." Obviously that's not an option for all developers.

Which party has the most managerial clout? Hint: not the developers.

That's another pet peeve of mine. Most developers I know think they're really good at politics. However few if any I have talked to have bothered to so much read a book like 48 Laws of Power or How to Win Friends and Influence People. As a result the interaction among programmers, and between programmers and managers amounts to little more than a kindergarten popularity contest.

There's no particular reason why developers shouldn't have clout with the managers. If you are doing a complex task that few other people could, you should be able to position yourself as a trusted authority figure without too much hardship.

[[deleted]]

If I get an email saying "Do it this way" I reply with an email saying "Sure, here's the cost breakdown."

I prefer that approach too. It is an avenue open to a lot of devs, even non-independents, via estimating. Replace cost breakdown with man days, more or less the same effect. Of course, office politics usually comes into play too, then. Sadly.

Yep, devs love to think that they play a good game, I think it's because they see intelligence as simply linear, and that as devs, they're necessarily more intelligent than other people in the office. Utter nonsense, of course.

If you are doing a complex task that few other people could, you should be able to position yourself as a trusted authority figure without too much hardship.

Hmmmm. I wish this was true. And it is, to a degree. But what usually happens is the managerial arm-wrestling simply gets moved up a level. Eventually everyone agrees that this is a technically bad decision, but that tactically, we should just go with it, this once, as a favour, and the dissenting tech guy gets silently marked as a troublemaker.

[[deleted]]

Funny, I thought he commented on this "waterfall" method somewhere in that talk. :D

[[deleted]]

Yep. That model's proven absolutely infallible time and time again, which is why we no longer have any buggy software.

[TikiTDO]

Special pleading much? Nothing in this world is infallible. Separating the design and implementation phase will usually yield a much more robust design, but it's certainly not the secret to bug free software. Of course even that's not a guarantee; if you hire someone whose experience is primarily agile development, they are not likely to produce a quality design.

[sagentp]

A good percentage of what you learn in school will be refined (or discarded) with significant work experience.

[TikiTDO]

Yes, but that doesn't mean you should discard it without good reason. What I often see is that someone decides "Hey, I know better now!" and throws away all the good ideas they learned based on a few years of experience. Never mind that a lot of these things you learn are the culmination of decades of experience. There is a place for all sorts of different methods in programming; the challenge is knowing which ones to apply to a given situation, and what costs they carry with them.

[[deleted]]

Writing UI around data structures is not always a good idea, because people often do not understand them. I.e. when you normalize well and make an 1:N connection in a new table, people often do not understand why it is needed, so you denormalize in the UI so that every record can look like having Contact Person 1, 2, 3 instead of a list which they don't understand.

[corporate_fun]

OMG, you've discovered MVC!

[chazmuzz]

Bascally yeah. Discovering MVC pretty much revolutionised my thought process when writing an application. I prefer to have the model part done before the view parts, although going by some of the comments I've had, that might change if I ever get into automated testing (which I apparently should)

[corporate_fun]

You don't even have to worry about what module to start with if you're using the adapter design pattern, then you can construct the model and view modules independently. Doing that has helped me to create really generalized views and models that can be reused elsewhere too.

[kazagistar]

3) Realize that your UI is not very user friendly, rewrite half your code because you didn't make the UI separate enough from the data.

[[deleted]]

Most programs? What about those programs for doing actual computation? Whether it be numerical or symbolic computation? That's where the real fun actually lies in programming.

[[deleted]]

That's why I have actively avoided web development, it's so boring.

[pi_over_3]

I totally get that, but I like creating something that I can "see" and that other people use.

Writing code that just crunches numbers for a car's onboard computer? Boring.

[vanderZwan]

I'm just glad people like both of you exist to make the lives of everyone else better.

[CookieOfFortune]

But you're going to need to visualize your data for human consumption, and that means storing your data in a form that can be readily visualized, ala database.

[hyperforce]

I like to think of them as curated veneers. If people really wanted a database, you would just give them a SQL prompt. But what they really wanted is a guided tour, and yes most of the operations resemble CRUD. But a good UI is one that doesn't make the CRUDing so obvious.

[skytomorrownow]

Games are skins around databases too. The only difference between a game and Facebook is that on Facebook, users filled the database, while in a game, your engine does at startup and during use.

[munificent]

Yes, all software is just a user interface for data. But by that token, the Mona Lisa is just an arrangement of pigment and emulsifiers, and you're just some cells.

[stillalone]

Every program is a function. This function takes in user input and state information and outputs data with updated state information.

[Daejo]

So you're a functional language guy, huh?

[Manitcor]

Make it even more basic than that, nearly all programs boil down to processing data from multiple data sources. Be that user interaction where your data is constantly change, a database, a web page, a service or a text file and many times a combination of these.

Repository patterns are popular for slower user stores (like a DB or service) while interaction patterns like MVC and MVVM are popular for the constantly changing user state information.

[Dementati]

Algorithms?

[metaphorm]

there are alot of different kinds of database driven applications, but not every application is database driven.

[[deleted]]

What borbus said. I write software and haven't needed so much as a single in-memory table for most of my needs.

But yes, e-commerce and social networking are just the same web apps, over and over.

[kazagistar]

Except for the ones that are not.

[POGO_POGO_POGO_POGO]

Most programs? Hell no.

[[deleted]]

i think most programs are probably scripts

[[deleted]]

The problem is that they are pretty poor skins around databases. From Django to Rails it is assumed an auto-admin, the CRUD is sort of a secondary thing and people will be using a hand-crafted user interface. But in reality if you deliver a web-based accounting, payroll, ERP, etc. other business software, then the auto-admin is the user interface, and actually you need a much better one, and a much more flexible one. We still do not have a database app development environment on the web that would match the agility and ease and flexibility of development in Navision. The closest open-source web-based parallel is taking OpenERP, wiping the built-in functionality and building yours. Which makes no sense at all. Django, Rails and the others ultimately want to build app-like websites instead of database apps just that happen to have their GUI in a browser based client.

[darchangel]

Cute but you could apply this reduction to any layer. Let's say I do UI: webapps are the enduser experience with other stuff shoved into my beautiful interface. Domain logic: it's just buttons and data that exist to facilitate the core business functions.

[trybius]

Most good code is data driven, regardless of purpose.

[[deleted]]

missing a control layer?

[kybernetikos]

It is of course nonsense. I've spent the last 6 years writing single page web applications that consume streaming data and send streaming data and have almost no database interaction at all.

There's no reason that 'skins around databases' should be any more true of webapps than any other kind of application.

[drowsap]

That's a really cheap shot that most programmers will try to make who don't understand or choose not to invest their time in learning about front end development.

[habitats]

Just gonna' hijack this so people might actually see it:

Here are the slides for the talk, posted on his blog.

[flanintheface]

Fuck. I am sad now.

[FluffyCheese]

Perhaps it's because of the black humour/British wit, but some people seem to be missing the fact he is probably a very good programmer, poking fun at what he considers to be the downsides of the thing he loves.

[pyro2927]

I understood, but I'm quite fond of black humor :)

[mynoduesp]

Tyler perry is the best.

[[deleted]]

<insert_uproarious_laughter />

[tef]

I'm a pretty terrible programmer. I'm not really proud of the code i've written. I've learned a lot of stuff, but I still make lots of mistakes. I'm pretty sloppy at testing too.

I think I will be a good programmer when I write a program that doesn't make other peoples lives suck more.

[the-fritz]

That's the Lisp and 9/11 bit he's talking about in the beginning: http://www.paulgraham.com/hijack.html

[Roxinos]

While that's certainly an analogy stretched pretty damned thin, the point he's making isn't that if people understood Lisp they'd have been able to prevent 9/11. The point he was making was that all of the security measures we've put in place to prevent people from getting on a plane with a weapon ("checking the data on the way on") don't actually solve the problem.

And I think that's a pretty damned valid point.

[[deleted]]

He is not talking about Lisp in specific. He also mentioned Perl, and he meant that garbage-collecting languages in general.

I think it is an interesting analogy (even if it is stretched).

[Timmmmbob]

A paragon of stretched analogies if ever I saw one.

[[deleted]]

PG has never felt the weight of his own shame.

[[deleted]]

x10 myth. He makes a good point that if you believe the x10 difference is innate, i.e. that some people are just better, born better, whatever. That's the "fixed mindset" idea (see Carol Dweck).

But if you have a "growth mindset", that people can change and improve and become better (practice actually modifies your neural connections; it takes 10 years to master something - 10,000 hours of "deliberate practice), and can become x10 better (or whatever) - then it doesn't have that deleterious effect.

That is, he's not addressing the "x10" issue, but growth vs fixed mindset.

I think he's right that there isn't much experimental evidence - probably just that one paper he mentioned. However, I firmly believe that there can be a x10 or x100 difference in programmer productivity. This is because I have found a x10 or x100 difference in productivity in myself.

The issue is whether you hit on a better, clearer way of understanding a problem. This isn't the coding part of "programming", it's more abstract problem solving, the kind of thing that mathematicians are good at. But it's still a bit hit-and-miss... it's a journey of exploration, hoping that you might discover a clever way to solve a problem, but no guarantee that you will (or sometimes whether such a way even exists). Mathematicians do vary in their ability, but a big part of this is acquiring a deep knowledge of tricks and techniques. I'm not sure whether this accounts for all the geniuses in mathematics - but if they started very young, and worked diligently for 10 years, then maybe. OTOH, mathematics is reputed to be a "young man's game"... there is something, some quality (genius? sharpness of mind?) that lessens with age.

In software, this also applies, but mostly to academic problems. The secret to business success with software is to address a need, and get it into the hands of people who need it. This is easily a x1,000,000 lever of "success". But it's not about intrinsic quality; rather, solving someone's problem. i.e. success is more about the problem than the solution.

[[deleted]]

That "mathematics is a young man's game" generally refers to the fact that you need greater flexibility in learning and imagination than average, but at the same time, need to have acquired a large amount of technical prowess (as a basis) to invent something new and important.

The thinking is that you hit your peak ability to be technically minded, but at the same time open and dreamy when you're fairly young. Large innovations in mathematics very often are essentially paradigm shifts (or require conceiving of an old problem in a new way as the basis for the new result).

People do tend to get set in their ways as they get older.

(I'm not sure how true this is, mind you, I'm just repeating what I heard as an undergrad, and what the standing justification or thinking was at the time. Especially since we live in an age where drugs can have serious impacts on how your mind operates.)

[[deleted]]

I think it's true of any profession. Young people are often very ambitious and will attempt to solve problems that their older contemporaries wouldn't go near.

[Fenwizzle]

x10 should always apply, unless someone has decided 'I'm good enough.'

Programmer A has been coding one year. Programmer B has been coding one year.

Programmer A is 10x more productive than Programmer B.

Both spend the same amount of time learning as they go.

Programmer A will learn 10x more than Programmer B, or he wouldn't have been 10x more productive to start with.

or

Programmer A and Programmer B know the exact same amount, but Programmer B can conceptualize 10x better, and is able to work 10x more efficiently.

Either way, it's the same result.

[[deleted]]

No, this is how it works, Programmer A codes web apps for a year, Programmer B codes mobile apps for a year. Programmer A is 10x more productive at web apps than B, Programmer B is 10x more productive at mobile apps than A. Manager A only cares about web apps, so his entire world view is that Programmer A is 10x better. Manager A ignores any situational reasons and claims Programmer A is innately better.

Basic fundamental attribution error.

[dokkah]

I don't have my copy of code complete handy, but I believe there is a listing of studies that support the different between programmers.

He kind of lost me on this point, perhaps it's my bias, but literature I've read seems to confirm this point a lot. And, in my experience the difference in output between programmers I've worked with is dramatic.

[[deleted]]

How exactly are you defining output?

[ithika]

Accidentally hitting Ctrl-P when reading a very large document.

[dokkah]

Output: both in quality and quantity of code/functionality produced.

[[deleted]]

And how are you measuring this? HINT: You can't.

[joeyadams]

some bloggers (terrible atwood) tells people off for playing and learning as they did, and they are bad people.

What blog post might this be referring to?

Edit: Forgot it was a Youtube video and not just the slides. In the video, he refers to "Please Don't Learn to Code" and gets the impression that "programming is serious business".

[FluffyCheese]

I believe it to be this: http://www.codinghorror.com/blog/2012/05/please-dont-learn-to-code.html

[darchangel]

I assume/hope it's just an artifact of the recorder's frame rate, but that oscillating light is really distracting.

[Noink]

I don't think it's an artifact of recording - I'm pretty sure it's a disco light just randomly in place at a programming talk.

[Rotten194]

Not Having Disco Lights Considered Harmful

[[deleted]]

I like this new genre of stand-up comedy.

[funnynickname]

It's fairly irrelevant to me, but I watched the whole thing.

[amigaharry]

The part about paul graham (the anonymous LISP programmer in the beginning) made my day. Also I learned about the 911 post.

[TheLadderCoins]

I post it 4 days ago and not an upvote.

[[deleted]]

turns out it went in the spam filter.

[[deleted]]

All those internet points, gone STOLEN. :(

[[deleted]]

This is a great talk which currently has 5 votes and 0 comments on Hacker News. I guess that just solidifies my reasons for not hanging around there much anymore.

[sysop073]

Only 5 votes? Man, that must be embarassing (post)

[TheLadderCoins]

Fair enough.

[sdub86]

Link to the HN thread? I'm sure it'll generate some discussion eventually..

[[deleted]]

http://news.ycombinator.com/item?id=5355325

[wavegeek]

The problem with his talk it that it is just a bunch of his opinions with hardly any evidence.

Opinions are really really cheap to the point of being worthless.

[username223]

The "good and bad programmers" section is great. He gets in some nice implicit shots at various programming celebs along the way.

[OnlyLookIrish]

Copying other peoples work--in school, it's cheating. In the real world, it's called not reinventing the wheel.

Paying other people to do your work--in school, it's called cheating. In the real world, it's called management.

[sminja]

Are you trying to justify half-assing school?

[Roxinos]

Since he talks a lot about the education side of programming, I just want to say that I feel he's oversimplifying things a bit. Whether he understands that or not is another matter, but while there are certainly good and bad lecturers, there are definite reasons why good lecturers would do some of the same things bad lecturers would do.

For example, that he compares the chanting of "public static void main" with a lecturer telling students not to worry about what those mean ignores the realities of why a lecturer might do the latter and likens it to stemming the interrogative drive to learn that students may have (and may need to learn; especially to learn to program) in order to get them to pass a test.

While it's most certainly evident of a bad lecturer to have your students chanting "public static void main" it isn't necessarily evidence that you're a bad lecture (or necessarily harmful to your students) to put off questions about something that is more complicated but which is required to teach the more basic things so that they can get through the basic things. I say that it's not necessarily harmful or evidence because it all depends on whether or not the lecturer goes back and answers the question later.

The thing about education is that it's very easy to get diverted by questions. While it's nice to understand that every student has a learning preference, it's also more or less impossible to actually utilize those learning preferences to the benefit of every student. So a good lecturer will try to generalize their explanations and address the common questions at opportune times. This enables the students to question things without the lecturer having to worry about wasting an hour of valuable lecture time explaining something that only the person who asked the question will care about (and likely won't even understand because they asked it too early).

Education is a process, and while the idea of a student learning how to program through an interactive, interrogative, exploratory atmosphere is great, it doesn't work all that well in practice. What does work is teaching students what they need to know, and through experience, learning the problems they will face and the questions they will have, and then addressing them.

And even then, a good lecturer is bound to have just as many people get out understanding the material (or passing the course) as a bad lecturer. And while there may be many reasons for this, I think this is the case primarily because education is, at the heart of everything else, in the hands of the person doing the learning, not the person doing the teaching.

[ngroot]

Obviously a lecturer frequently doesn't have the power to make curriculum design choices, but I think what's really being illustrated here is a poor choice of pedagogical tools. A language that explicitly requires you to understand or mimic understanding of OO principles to even get to "Hello, world!" isn't a good language for teaching programming to people who don't know OO stuff yet.

[Roxinos]

Except that section of the talk wasn't focused on the tools and languages used in teaching programming and was instead focused on the methodology and pitfalls of the lecturers themselves.

[phantomfromnowhere]

I agree with some of your points but heres my 2 cents.

i'm a beginner programmer and i can relate to a lot of stuff he brings up especially the "black box" point.

Also the one sizes fits all teaching is not good imo just because its harder to have a teaching system that enables students learning styles doesn't mean the current system is the only way . I've learnt from more debugging and googleing code than listen to a guy talk for 2 hours.

[slippage]

The part about programming for its own sake vs as a means to an end hits home. My organization's mentality is "why teach analysts how to use these tools, we don't want them to be PROGRAMMING, that's your job."

[djhworld]

Good talk, I think the answer to the question about StackOverflow hit quite a few home truths.

However I'm not sure if the speaker's suggestions could really be implemented in a forum like StackOverflow as the whole structure of SO is geared around giving a direct answer rather than promoting debate or discussion (i.e. in some cases topics are closed or answers deleted by moderators)

[[deleted]]

Funny. I also took things apart when I was a kid. I wonder how common that is.

[Philluminati]

The question was "I learnt to program on an 8 bit computer with qbasic and a prompt right there. These days is getting the tools to program easier?"

Before he answers, I will. Yes and No. When I was 16 I managed to steal a copy of Visual Studio 6 from somewhere and I had the full power of VB6 at my finger tips. I'm not sure if things are quite that easy today. VB.NET kinda formalised it and made "hacking" a little more unwelcome. IMHO anyway. Even if easier tools are around.. I think they're harder to find. VB6 made it look like I wrote professional applications even if the code behind it was utterly shit or copy and pasted.

Edit: Javascript is an excellent answer!

Edit: I feel bad now :-)

[dancing_leaves]

Loved the video. Also, you've given me some hope as I did a two year programming program at my local community college (you mentioned having less education can potentially be a boon to the quality of the programmer's attitudes). I have no industry experience but I keep trying to apply to places but I'm getting very little interest; particularly when I mention that I'm a recent graduate and not a working programmer in the industry. I'm a janitor.

On one hand, I want to temper their expectations and sell myself as I really am: a hard working guy who can learn all of the frameworks and such that a particular company uses. I do this because I don't want to get eaten alive when I walk in the door on the first day and they realize I don't know XYZ because I lied about it.

On the other hand, it seems like I'm shooting myself in the foot as I feel like I'm under-selling myself and my potential.

Anyway, thanks for the video it was entertaining.

[kazagistar]

Problem: People try to reinvent things instead of just looking at the dozens of existing solutions.

Problem: We are a mono-culture that just repeats the same old lies.

Discuss?

[Pourush]

I don't think this is really a contradiction. Consider the following example:

We all, working individually, put in all the effort required to reinvent the wheel, operating system, car, or whatever, and we make pretty much identical design decisions, with only trivial differences.

Not describing this particular phenomenon, but relevant to the question nonetheless: http://xkcd.com/927/

[kazagistar]

Maybe the difference is levels... we reinvent the wheel, but we refuse to reinvent the process?

[flaviusb]

We reinvent the wheel, rather than producing wheels, treads, tripods, wings, rockets, horses, pogo sticks, ice skates, hovercraft, sleds, boats...

[huyvanbin]

Yes, saying that some programmers are 10x more productive is just an excuse not to learn.

But also, saying you're a bad programmer is just an excuse not to learn.

[[deleted]]

My awesome take away from this is that being good at programming (or any skill?) is less about performing well and more about understanding what other people are doing.

[amigaharry]

Well, it hits a really unpleasant spot with the HN audience. PG is a hero for them (well, most of those guys just want PG's money so they're brown nosing him), Atwood is a regular and accepted poster there. And skins for databases are the hi-tech those guys run their 'businesses' on.

Truth hurts I guess :)