I am a real programmer damnit!
-
‘Real’ Programming Is an Elitist Myth
When people build a database to manage reading lists or feed their neighbors, that’s coding—and culture.
-
-
But it sure does work. I've noticed that when software lets nonprogrammers do programmer things, it makes the programmers nervous. Suddenly they stop smiling indulgently and start talking about what “real programming” is. This has been the history of the World Wide Web, for example. Go ahead and tweet “HTML is real programming,” and watch programmers show up in your mentions to go, “As if.” Except when you write a web page in HTML, you are creating a data model that will be interpreted by the browser. This is what programming is.
LOL. That's not people being nervous. It's about knowing all the stuff you're missing. Sure, it's fine for something simple that not many people need to use. It falls down as soon as you have multiple users or security requirements or any desire for data integrity. Which, to be fair, is not always required.
But programmer culture tends to devalue data. The database is boring, old, staid technology. Managing it is an acronym job (DBA, for database administrator).
Eh...that's not managing data. That's keeping the lights on. The programmers still have to...err...program stuff to do anything useful with the data.
Anyways...why not post this into the sidebar?
-
@boomzilla said in I am a real programmer damnit!:
Anyways...why not post this into the sidebar?
Probably a better spot for. I have no objection to it being moved.
-
@Dragoon I don't think the guy understands... things.
There is much more to developing a useful computer program than just "coding."
The BA's job is to figure out what the program needs to do and how it fits into the overall business. Not to type crap into Visual Studio. That's not "coding."
The tester's job is mainly to think of ways that the design could go wrong and plan tests to see if those things are actually occuring. You have to type a little bit into Visual Studio, but it's mostly not "coding."
Being the DBA and administering the database isn't "coding." Neither is doing IT plumbing and keeping the network running. Neither is project management.
Hell, even the actual software developer is probably spending more time on the design and the plan than on actually typing crap into Visual Studio.
Also, when
I get asked a lot about learning to code
They're probably pointing out that his article kind of sucks.
-
@boomzilla said in I am a real programmer damnit!:
LOL. That's not people being nervous.
Sure it is. Because we're going to have to fix their shit.
-
@boomzilla said in I am a real programmer damnit!:
But programmer culture tends to devalue data.
This is also not even remotely true. And any decent programmer has no problems maintaining a database. It's not hard. Plus, who do they think wrote the database server and the tools to manage it...the code gods?
EDIT: descent to decent
-
@CodeJunkie said in I am a real programmer damnit!:
@boomzilla said in I am a real programmer damnit!:
But programmer culture tends to devalue data.
This is also not even remotely true. And any descent programmer has no problems maintaining a database. It's not hard. Plus, who do they think wrote the database server and the tools to manage it...the code gods?
The programmers on the ascent!
-
@CodeJunkie said in I am a real programmer damnit!:
@boomzilla said in I am a real programmer damnit!:
But programmer culture tends to devalue data.
This is also not even remotely true. And any descent programmer has no problems maintaining a database. It's not hard. Plus, who do they think wrote the database server and the tools to manage it...the code gods?
You click that button there, then that one - no THAT one, then wave your hands and it's done. Hey, I watch CSI, I know how it works.
-
@CodeJunkie said in I am a real programmer damnit!:
And any descent programmer has no problems maintaining a database.
Is a descent programmer always going down?
edit: sorta
-
@loopback0 said in I am a real programmer damnit!:
@CodeJunkie said in I am a real programmer damnit!:
And any descent programmer has no problems maintaining a database.
Is a descent programmer always going down?
edit: sorta
bah...fixed.
-
@CodeJunkie said in I am a real programmer damnit!:
descent programmer...the code gods
The programmer who descended from on high?
-
@HardwareGeek said in I am a real programmer damnit!:
@CodeJunkie said in I am a real programmer damnit!:
descent programmer...the code gods
The programmer who descended from on high?
Just a bad translation from "The programmer who descended from a high"
-
I've always loved that moment when someone shows you the thing they built for tracking books they've read or for their jewelry business. Amateur software is magical because you can see the seams and how people wrestled the computer. Like outsider art.
I think there's some value in that. It's basically how we all started long ago, and it shows how the people at least tried to handle the problem analytically instead of throwing their hands up as soon as they see anything computer related. It's really a starting point for learning.
But where it gets really problematic, as mentioned by others, is when such a crutch becomes business critical for something it doesn't scale to. In that case you do need some "real programmers" and not something cobbled together.It's one of the most soothing activities known to humankind, taking big piles of messy data and massaging them into the rigid structure required of a relational database. It's true power.
Sounds like this guy completely missed the hype around NoSQL garbage.
-
Ha! The notion that something thrown together by people having only domain knowledge can stand in for a professional approach to data is ludicrous. You generally don't fix your own teeth. Division of labor exists for a reason, it enables complex solutions, fuels the economy, and so on, and on.
But I also love how real programmers get panties in a bunch about this thing. Let me put it this way - if you ever feel threatened by this, generally you must be an arrogant bastard and all your shit sucks. Doubly so if you're a tecknology enthusiast dick who loves this or that modern crapware (or all software) or have a shit-eating grin in your avatar.
What I mean by that is that real programmers overly fixate on tecknology itself. It's good to be passionate about something, but what I'm seeing these days is almost cultish kinds of worship. That's exactly the wrong way, I'm afraid.
Alright, so the layman approach only appears to work, because it ignores long-term consequences. It's useful to get something up quickly, but it does create garbage data (and data garbage), usually performs poorly, and at some point it begins to stink terribly, and there's bound to be lots of crying (bloody stupid computers!) when shit eventually hits the fan.
The problem is, yes, "real" programmers do have heads so far up their asses, with all their clever tecknology that it tends to go the same way. Plan for this thing, didn't foresee this thing, legacy support starts even before the first release, use this framework, framework is deprecated, bugs in code, patch this, hotfix this, hack around this, bugs in some third-party layer, we apologize (not really) for inconvenience, licensing changes, "as is, not fit for particular purpose", looming deadlines, insufficient processing power, sunk costs, runaway costs, marketing lies, and finally - a bunch of "real" programmers that just fucking ain't so.
Laymen take certain pride in tedious work that real programmers believe can be easily solved with a computer. That's an unfortunate case of tunnel vision. Yes, it's easy to do with 90% percent of data, some 9% will have to be bent into submission with clever and adaptable design. The remaining 1% will always be trouble. Computers are indeed bloody stupid. For example, a human will treat "five!!" as 5 and doesn't care if it ought to be double, integer or string or whatever. A computer will fail. Fair enough, you can't foresee and handle all possible cases, at some point you have to tell "something went wrong" (no, you quacks, ML is not an answer).
Unfortunately real programmers haven't found a simple way to tell computers what to do. The industry is only about 100 years old. We're cavemen with access to industrial power tools. We're mostly in the phase of turning solutions into better problems while the society expects the opposite. With luck in another hundred years maybe we'll figure it out.
Signed, Catus Ignoramus
-
@Dragoon said in I am a real programmer damnit!:
When people build a database to manage reading lists or feed their neighbors, that’s coding—and culture.
Thing is, real programming is an elite craft. You wouldn't want a hobbyist electrician to wire up your home or a hobbyist architect to design a bridge you were going to drive across; anyone can take one look at that idea and see it would be sheer insanity. Well, it's just as insane to let hobbyist coders build business-critical or (especially!) security-critical software.
I think a big part of the problem comes down to tools and materials. A kid can play around with Lego Technic or Capsela and learn about electricity safely, but when AC power is involved, you know you need someone who knows what they're doing. An amateur can build toy bridges out of wood and glue, but when the job calls for steel and cement, it's a pretty clear sign that this is a job best left to the experts.
ISTM we don't really have that obvious dividing line in programming. Anyone can download professional-grade dev tools for free, and programming is esoteric enough (and diverse enough in scope) that there are no obvious conditions the average layman could point to and say "this is a task that really needs a trained professional!"
-
@Mason_Wheeler said in I am a real programmer damnit!:
Thing is, real programming is an elite craft. You wouldn't want a hobbyist electrician to wire up your home or a hobbyist architect to design a bridge you were going to drive across; anyone can take one look at that idea and see it would be sheer insanity. Well, it's just as insane to let hobbyist coders build business-critical or (especially!) security-critical software.
Oh, hey! I've wired up AC, and the most training I got was a high school electronics class. It's... well, half the run is definitely up to code. The other half almost certainly isn't. But it works!
I'm sure my wiring would be better if done by a professional, but a) it works, and b) the wiring project is small because I know when to stop. If I had a high current draw on that line, it would probably work fine, but I'm not about to chance it.
I think a big part of the problem comes down to tools and materials. A kid can play around with Lego Technic or Capsela and learn about electricity safely, but when AC power is involved, you know you need someone who knows what they're doing. An amateur can build toy bridges out of wood and glue, but when the job calls for steel and cement, it's a pretty clear sign that this is a job best left to the experts.
ISTM we don't really have that obvious dividing line in programming. Anyone can download professional-grade dev tools for free, and programming is esoteric enough (and diverse enough in scope) that there are no obvious conditions the average layman could point to and say "this is a task that really needs a trained professional!"
We have entire businesses based on Excel spreadsheets. Those businesses are, sooner or later, going to end up in serious trouble, even though it works for now. But when I read that article (especially the organizing-volunteers part), I see a bunch of people who did enough "coding" to get the job done, and it works well enough for them. Sure, a bespoke solution could be better in a million different ways, but they're proabaly not losing too much productivity to the restrictions of Airtable, and they're Getting Shit Done without it costing terribly much.
The author should definitely Lern 2 Cowd. But the little toy databases he's talking about are a great place to start.
-
@Applied-Mediocrity said in I am a real programmer damnit!:
real programmers
Your're confusing real programmers for wanna be real programmers. The exact assholes that fixate on the daily fad crapware who can't think for themselves and have no way of knowing good software from the bad. The thing is that the industry, to some degree, has been taken over by them. It's why there are things like NoSQL and other such garbage.
-
@CodeJunkie said in I am a real programmer damnit!:
Your're confusing real programmers for
wanna be realimaginary programmers.It's a complex topic.
-
@HardwareGeek said in I am a real programmer damnit!:
@CodeJunkie said in I am a real programmer damnit!:
Your're confusing real programmers for
wanna be realimaginary programmers.It's a complex topic.
Well, yeah.
-
@CodeJunkie said in I am a real programmer damnit!:
@HardwareGeek said in I am a real programmer damnit!:
@CodeJunkie said in I am a real programmer damnit!:
Your're confusing real programmers for
wanna be realimaginary programmers.It's a complex topic.
Well, yeah.
One could also say that real programmers don't refer to themselves that way.
-
As soon as I saw that graphic, I knew I was going to be rolling my eyes all through the article.
The gauntlet that a real programmer has to run through these days just to get a foot in the door is ridiculous. As soon as you engage the critical thinking part of your brain, somebody will inevitably have their views challenged and when that happens you're toast.
-
@HardwareGeek said in I am a real programmer damnit!:
@CodeJunkie said in I am a real programmer damnit!:
Your're confusing real programmers for
wanna be realimaginary programmers.It's a complex topic.
-
@CodeJunkie said in I am a real programmer damnit!:
@CodeJunkie said in I am a real programmer damnit!:
@HardwareGeek said in I am a real programmer damnit!:
@CodeJunkie said in I am a real programmer damnit!:
Your're confusing real programmers for
wanna be realimaginary programmers.It's a complex topic.
Well, yeah.
One could also say that real programmers don't refer to themselves that way.
I've been referring to myself as a "Software Engineer". My business card says "Senior Software Engineer", And I'm very well aware that it says jack about what I actually do all day for a living.
My take on what's "real" programming though? Anything with conditional logic.
-
@Dragoon said in I am a real programmer damnit!:
I've noticed that when software lets nonprogrammers do programmer things, it makes the programmers nervous. Suddenly they stop smiling indulgently and start talking about what “real programming” is.
I've only ever noticed this low-key (e.g. CLI vs GUI).
It's also irrelevant, since we should always be working on convenience scripts to reduce repetition. The first people to be putting us out of work should always be us.
And there will still be work.
-
@GuyWhoKilledBear said in I am a real programmer damnit!:
Being the DBA and administering the database isn't "coding."
That'd depend on how many stored procedures are in use. Looking after them (and ensuring that they go fast where required) is definitely one of the tasks of the DBA, and that's programming at least in part.
-
@dcon said in I am a real programmer damnit!:
@HardwareGeek said in I am a real programmer damnit!:
@CodeJunkie said in I am a real programmer damnit!:
descent programmer...the code gods
The programmer who descended from on high?
Just a bad translation from "The programmer who descended from a high"
The Raku thread is
-
My take on all this is that there's several levels of programming.
- Walled garden programming is in a cut-down environment like Scratch. You can do quite a bit within it, but you're restricted to the playpen.
- Happy-path programming is where you have a system that is only intended to work where everything lines up just right. You might be interacting with the real world like this, but the moment anything goes wrong the code either blows up or wedges everything far wrong-er.
- “Real” programming, which takes those happy paths and adds in all the stuff for dealing with awkward edge cases and ensuring that things are secure and scalable and maintainable and so on. (How much of which depends on the details, of course.)
The first is for learning, and that's a valuable goal right there, but we shouldn't keep the kid gloves on forever for any individual. The second is where a lot of people can get to with relatively little effort; you can get shit done at that point, at least for a while, but you still need to keep a close eye on things in case stuff goes wrong. The third is where professionals are usually operating, and they're generally trying to make code that works without being babysat by its creators. It's also exponentially more difficult than just coding up the happy path.
-
@dkf said in I am a real programmer damnit!:
@GuyWhoKilledBear said in I am a real programmer damnit!:
Being the DBA and administering the database isn't "coding."
That'd depend on how many stored procedures are in use. Looking after them (and ensuring that they go fast where required) is definitely one of the tasks of the DBA, and that's programming at least in part.
Yeah, but writing stored procedures that run inside the DB is ideally a small part of the DBAs job. It should mainly be more about system administration, right?
And like the tester I mentioned, sometimes the DBA needs to write code. But that's not the important part of the job.
The problem with TFA is that like so much of the media, it fetishizes "coding" to a degree that's not reflective of how the industry actually works.
For example, DBA is an important job. But it's one that usually doesn't require a lot of "coding."
-
@Dragoon said in I am a real programmer damnit!:
When people build a database to manage reading lists or feed their neighbors, that’s coding—and culture.
“Real” coders in my experience have often sneered at this kind of software, even back when it was just FileMaker and Microsoft Access managing the flower shop or tracking the cats at the animal shelter.
Not really. What we hate is when we get requirements like "Just make it work like excel!"
Most of us don't give a flying fuck what you get up to as long as we don't have to maintain the codethulian horror you create.But it sure does work. I've noticed that when software lets nonprogrammers do programmer things, it makes the programmers nervous.
You see, we don't get nervous. At least not us real programmers. If you can solve simple problems on your own, great! That means I won't have to bother with it.
And when you realize that what you built piss all over your data, or it won't scale at all, or whatever else, us real developers get to build a proper system for you. We've been doing this for similar excel horrors for decades now, this is just a new tech stack and it's possibly a lot better.
Either way, it won't steal any work we'd want to do to begin with.This has been the history of the World Wide Web, for example.
Hey, you're right but then you go and fuck the wrong horse again.
Go ahead and tweet “HTML is real programming,” and watch programmers show up in your mentions to go, “As if.” Except when you write a web page in HTML, you are creating a data model that will be interpreted by the browser. This is what programming is.
HTML is not programming, it is document editing. Fiddling with HTML is no more programming than fiddling with word documents. HTML is in no way a data model, its a presentation model.
And even so, making a data model is a part of what developers do, but far from the only thing. Data models, data flow and data representation are the core things, but on top of that we have business rules, security, tech stack and all sorts of horrible shenanigans.But programmer culture tends to devalue data. The database is boring, old, staid technology. Managing it is an acronym job (DBA, for database administrator). You set up your tables and columns, and add rows of data.
Man, you really don't understand data or databases, or data modelling.
Programming is where the action is. Sure, 80 percent of your code in Swift, Java, C#, or JavaScript is about pulling data out of a database and putting data back in.
No. The actual CRUD stuff is usually handled by something like the GenericDao-pattern. A vast majority of the code I write is actually business rules, or some sort of data transfer, and data transformation.
But that other 20 percent is where the action is, where you make the next big world-shaking thing. Which is great! Go to!
Eh, not really. The word shaking things is a vanishingly small part of software. And it's quite a bit less fun than the startups tell you.
But don't forget that most of the world is trying to manage their small business with a really messy spreadsheet.
Hey, have fun with that spreadsheet, and when you outgrow it, find a good firm that can build a proper system for you. We're here for you.
-
@CodeJunkie said in I am a real programmer damnit!:
@CodeJunkie said in I am a real programmer damnit!:
@HardwareGeek said in I am a real programmer damnit!:
@CodeJunkie said in I am a real programmer damnit!:
Your're confusing real programmers for
wanna be realimaginary programmers.It's a complex topic.
Well, yeah.
One could also say that real programmers don't refer to themselves that way.
Real Programming has never been tried.
-
@dkf said in I am a real programmer damnit!:
@GuyWhoKilledBear said in I am a real programmer damnit!:
Being the DBA and administering the database isn't "coding."
That'd depend on how many stored procedures are in use. Looking after them (and ensuring that they go fast where required) is definitely one of the tasks of the DBA, and that's programming at least in part.
No, I get it. I'm sure there are DBAs out there who do that sort of thing. I've just never encountered one.
-
This guy is amateur hour even by my low standards. We're afraid of the amateurs coming in because we'll have to clean up the mess they've made. My career so far is making the mess less of a mess. Until I entered start up land anyway. Jesus fuck that place.
crux of things, is there in the database
Some of us would argue its that simple and easy to use ui that your wife is using. The data model can be a mess but if the ui can gloss over it you're on to a winner.
-
@boomzilla My brother swears he used to work somewhere that had database developers, defined as "you tell us what you need, we'll write the stored procedures for you." He used to complain because all they did was hold up development and bailed for a job 1400 miles away. I've only seen shops with no DBAs (everybody's a "full stack" developer) or the DBA is strictly a custodial role (reboot the server when it hangs and update MSSQL every 4-5 years).
-
@boomzilla said in I am a real programmer damnit!:
@dkf said in I am a real programmer damnit!:
@GuyWhoKilledBear said in I am a real programmer damnit!:
Being the DBA and administering the database isn't "coding."
That'd depend on how many stored procedures are in use. Looking after them (and ensuring that they go fast where required) is definitely one of the tasks of the DBA, and that's programming at least in part.
No, I get it. I'm sure there are DBAs out there who do that sort of thing. I've just never encountered one.
At my first job out of college that was something that our DBA did. It was not required that stored procedures go through him before we could deploy, but he did monitor their performance and would notify you if they were slower than he thought they should be. He was a really nice guy and had no problem sitting down and explaining why your stored proc was shit (and lets face it, if I wrote it, it really was shit) and how to improve it.
-
@Zenith said in I am a real programmer damnit!:
@boomzilla My brother swears he used to work somewhere that had database developers, defined as "you tell us what you need, we'll write the stored procedures for you."
Lies! They're gone. ORMs killed them off a decade ago and no-one noticed that dbs have gone to shit yet. Right now kubernetes is trying to kill off devops now. I'm getting the Marsh mellows ready for this tire fire.
-
@DogsB said in I am a real programmer damnit!:
Right now kubernetes is trying to kill off devops now.
In which universe are Kubernetes and DevOps somehow opposites?
(Fun
act: My auto-correct turned "Kubernetes" into "Liver eyes".)
-
Re: I am a real programmer damnit!
I agree with DogsB that DBA is more of a formality nowadays because of ORMs. And because the requirement that logic should be part of the software (a service which the ORMs provide) and not part of the data(base), businesses reduced databases to a storage-slave like any HDD drive.
-
@Zenith said in I am a real programmer damnit!:
@boomzilla My brother swears he used to work somewhere that had database developers, defined as "you tell us what you need, we'll write the stored procedures for you." He used to complain because all they did was hold up development and bailed for a job 1400 miles away. I've only seen shops with no DBAs (everybody's a "full stack" developer) or the DBA is strictly a custodial role (reboot the server when it hangs and update MSSQL every 4-5 years).
It was like that back when I worked at a big bank here in the states between 2004 and 2008. It was irritating because we would have to go through the DBAs for anything being added to the database...even just fields to tables which were related to the software our department maintained. And they wanted to question every fucking thing you were doing and they didn't understand anything we did. So they were a huge bottleneck. We didn't often change the database, but when we had to, it was a PITA.
The role of DBA is mostly gone, I would expect big companies probably still have them, but who knows. I left that bank gig and went to work for a software dev company and the software engineers controlled the database. We did have a network group though which maintained all the servers and network and everything so no DevOps there....but where I am now DevOps is a thing.
Now my first real software engineering gig was at a software dev company around 2000 ish ... we had a DBA, but he was really only there for support and guidance and to make sure the DBs were performing well. We had a lot of junior devs and kids right out of college and what not so he was good to have on staff. He was a nice guy.
-
@Flips said in I am a real programmer damnit!:
I agree with DogsB that DBA is more of a formality nowadays because of ORMs.
I wouldn't attribute it to ORMs per se. But I do think that experienced programmers proved they weren't necessary...especially in software development companies and companies that have real development teams. I can see where they would be useful in businesses where their primary business is not software, but they have DBs for software they use to run their business. Course these guys would probably also be the network admins as well...basically wearing multiple tech hats.
-
@CodeJunkie per se*
-
-
@dfdub said in I am a real programmer damnit!:
@DogsB said in I am a real programmer damnit!:
Right now kubernetes is trying to kill off devops now.
In which universe are Kubernetes and DevOps somehow opposites?
(Fun
act: My auto-correct turned "Kubernetes" into "Liver eyes".)YMMV but from what I've seen is that backend developers are expected to pick it up and manage it. BE developers over the last .5 of my career have become dba/devops/code wranglers/automated test writers.
Kubernetes is meant to make Devonshire (Autocorrect I'm leaving it but devops) easier.
-
@DogsB said in I am a real programmer damnit!:
YMMV but from what I've seen is that backend developers are expected to pick it up and manage it.
No, the infrastructure team is supposed to manage it and all the developers are supposed to do is provide the pod definitions. Which is kind of the whole point of DevOps: The developers declaratively define the infrastructure they need and then start their containers on actual infrastructure managed by operations, thus bridging the gap between dev and ops. Sure, you can have a dedicated "DevOps guy" on your team who handles that, but that's entirely optional and potentially not even a good practice.
-
@dfdub said in I am a real programmer damnit!:
Sure, you can have a dedicated "DevOps guy" on your team who handles that, but that's entirely optional and potentially not even a good practice.
Generally, yes, ops should be done by different people, but somewhere down the road someone decided programmers didn't have enough to do. DevOps can go fuck itself IMHO. It starts to impact your actual dev time on projects, especially when you have to handle emergencies related servers and whatever for other projects/clients.
-
@CodeJunkie said in I am a real programmer damnit!:
It starts to impact your actual dev time on projects, especially when you have to handle emergencies related servers and whatever for other projects/clients.
Well, yeah, but having to debug infrastructure issues in production as a developer is not "DevOps", it's "we just fired Ops". You're supposed to supply the deployment configuration (scripts/Docker images/...), but ops is still supposed to babysit the actual server.
-
@dfdub As opposed to operations having to debug programming issues in production...
I literally have no idea what DevOps is supposed to be. I used to understand it as developers doing operations, like in a small shop. Then it turned into managing and deploying builds. Now it's Team Fortress in the Azure cloud. Does somebody in a halfway sane work environment know what the hell it really is?
-
@dfdub said in I am a real programmer damnit!:
Well, yeah, but having to debug infrastructure issues in production as a developer is not "DevOps"
This is generally what it is....not that I'm saying it is good or correct, but usually the case. Where I'm at right now we have no operations department.
-
@Zenith said in I am a real programmer damnit!:
I literally have no idea what DevOps is supposed to be.
It's supposed to be an umbrella term for practices that bridge the gap between development and operations. The most common ones would be CI/CD (developers test their code in a realistic environment) plus release automation and all those "infrastructure as code" approaches (Dockerfiles / Kubernetes / Ansible / …). So basically all the tooling that helps automate releases and deployments so that both developers and operations can focus on the important stuff.
-
@CodeJunkie said in I am a real programmer damnit!:
Generally, yes, ops should be done by different people, but somewhere down the road someone decided programmers didn't have enough to do. DevOps can go fuck itself IMHO. It starts to impact your actual dev time on projects, especially when you have to handle emergencies related servers and whatever for other projects/clients.
It all depends what your work environment is like. I would give anything to go back to where I controlled practically everything. Have you ever heard the saying "don't shit where you eat/sleep?" You'd find those distracting emergencies would be fewer and further between if the responsibility and accountability fell on the same team if not person. When they don't, that's when "just throw it over the wall" and "ride it 'till the wheels fall off" take over.
