What Successful Programmers Do That Others Don't: Dave Cutler

Dave Cutler explains what successful software engineers do that others do not.

[loganmedia]

I learned the hard way, never put in extra hours unless there is a clear and guaranteed reward attached. Do not fall for vague promises or peer pressure.

[jackflash]

As a successful Porsche tech, my secret was. Treat every job like a mountain. All mountains can be conquered.. one step at a time.
Walk up the mountain, walk down the mountain. Step by step.
Start off with the big goal and break the job into mini goals then get busy.
Achieving the mini goals gives you the drive to keep going.

[thecalvinprice]

A mantra in my life is 'If it's possible for it to break, however obscurely, a user will find a way to break it'.

[paulsan]

I worked at Microsoft through the 90’s providing support to hardware vendors that were writing kernel-mode device drivers for their products. I never interfaced with Dave directly. Rather I talked with the programmers that were one level beneath Dave to help me with customers’ problems that I couldn’t figure out. Still, every summer I would see Dave at a couple of IndyCar races. Dave drove for the Microsoft sponsored team in a subordinate racing series that the series name escapes me. That’s how I mainly remember Dave.

[Obamanamamama]

Dave cutler looks amazing for being 81

[abdulelahaljeffery]

1:44 Love Fred Brooks quote from his great book "The Mythical Man Month" he wrote:

"Thinkers are rare; doers are rarer; and thinker-doers are rarest."

[StillAliveAndKicking_]

The problem with Cutler’s viewpoint is that a company must incentivise good code, and taking responsibility. More often than not managers don’t know whether a job is easy or hard, and they don’t reward conscientious work. I once worked on some old software we had adapted for a new product. It had a custom coded list view. Adding a new column was a pain. So I modifed the code to make it really easy to add new columns. A year or two later I was laid off as the company was in trouble. I later found out that a colleague used my framework to add a new column, and because he did it so fast, this colleague gained a reputation for being talented. Hence I was laid off before him. It does not pay to be conscientious.

In another company a colleague always bodged a task. He would take the quick and easy route, which was to reuse an existing table for a new object. Invariably he broke other objects that used the same table. I had to fix the bugs he created and it was a nightmare as so many objects shared the same table, and the behaviour of each object was not documented. He was the director’s darling because he was so fast. Had he added a new table for the new object, it would have taken him maybe 8 days rather than 3. But his approach meant days were wasted dealing with an unhappy customer, then countless days were wasted fixing and testing the bug, and in future we lost countless days because it was so hard to modify the existing objects because the code had become so complex. Thus in the long run he made customers unhappy, and cost us a lot of time and money. But he was the company owner’s little darling.

In my last job, I completely recreated from scratch an existing product, which showed in realtime a 3D display of the capacitance on a touchscreen, using new tech (WPF) with a far superior look and feel and enhanced capabilities. The director told me I had done the work far quicker than expected, and it looked really good. He and the other directors still treated me like crap, so I left.

So no, you soon learn that you arrive at 9, you do your work, then leave at 5. And you don’t stress out over the product. You do work that furthers your career then you fook off.

[PontschPauPau]

A big problem in modern software development is that if you go above and beyond, you're also taking additional responsibility and the chances of getting noticed or rewarded in a big organization are slim, especially when you're "just" a coder in the trenches. There's a ton of downside, because if you take on additional responsibility you have to own it, and make sure you don't make a mess, but the upside is, what, that you're expected to do that much more work for the same pay going forward, indefinitely? A lot of people that start out as "Doers" end up realizing that they're just not being rewarded for their effort. There is zero incentive to being a "Doer" in most larger organizations.

Successful people certainly don't become successful by doing a whole lot of extra work for free.

[roguecheddar]

As a business applications programmer for over thirty years, I've always tried to be a thinker/doer and clean up my own and other coders bugs, but always amazed how often I'd be sabotaged by management who would rather have new programs written to mask an existing program problem, as opposed to going back and fixing it at the source. They never want to waste extra time doing it right the first time, but can always find time to do it over and over and over... And I can't tell you how many times I've had to debug 3rd party vendor software that was riddled with bugs or their documentation didn't match what their software actually did or didn't do. If they gave A.I. the task of going through every commercial software ever published to root out bugs, it would be forever busy and we wouldn't have to worry about A.I. ever taking over the world.

[muddyexport]

Thanks again.
PS, when I was working for a paycheck fixing bugs was a large part of my job and I loved it. I got paid for playing and having fun -- couldn't wait to get to work and had to be reminded to go home. I know that is the definition of a nerd so I am one. Making the code right was like mowing the grass, I could see the progress. Retired but still tinkering with new to me code.

[gerakore]

I used to regret not working in a corporate team setting, but now I see the value in going solo. Managing the entire development life cycle, including design, implementation, debugging, testing, upgrading, and maintenance, is quite daunting. This solo journey has taught me self-sufficiency, but without oversight, I'm aware I may have picked up some less-than-ideal habits. The tech industry evolves rapidly, and I fear I've fallen behind.

In the future, I plan to transition into a more structured team environment, one that's up-to-date with industry standards. I believe experiencing both sides of the coin will provide a well-rounded perspective and ultimately benefit my career.

[Lupinicus]

As a mainframe assembler programmer on systems/kernel code in IBM's ACP/TPF in the 80s I enjoyed debugging. The satisfaction of finding solutions was great, plus it taught me things that inevitably improved my coding.

[YolandaPlayne]

Reminds me of how I started and how I ended my career. I learned very early the same lessons, but another lesson I learned is it didn't matter if I got things done. The only thing that mattered was making the management look good in metrics. They didn't care what I did with my time and only wanted my opinion in public despite me working on back end problems that needed to stay private.

[TheMisterGuy]

Never do this. Go home at 5:00 PM. If the thing isn't going to ship on time, that's management's fault. Doing extra work for no extra money just covers up management's failure and shifts the burden to you and the credit to them. Unless you're the owner or it's your own business, then you need to make call. Otherwise you're trading the limited time of your life for someone else's bank account.

[malectric]

I like this man's thinking. I cannot live with bugs in my code. I spend time - probably far too much - going over stuff I've written in the past to see where I could have optimized or done it better. And when it comes to a current program I'm writing, I cannot let it go if it doesn't work correctly.

[matt_kelly]

The second half he's talking about what I call "the good idea club", all theory/planning and no followthrough. I resigned from my last company because they hired a person like that. Had a great idea for a new wonderous platform that would solve all future problems, would only take a few years to build, and got all the management to buy in. Meanwhile my team was already building that same platform and already had paying clients, but we building the features as we went along. The "new" platform was going to replace the old one and that's just how it was going to be according to management, so I resigned in protest at such a short-sighted plan. Fast forward a year and the new platform failed, guy moved on to another company, and the "old" platform is being used again.

[rtdgreg]

That’s a blast from the past. Happy days back in 1973? Programming pdp11 in assembler. Early adopter of RSX 11/M. Lots of dialogue with Dave Cutler. Can’t remember how we “talked” - nowadays it would be email. Could it have been the old fashioned jellingbone? Me in UK & Sweden. Dave on west coast USA. Great guy.

[jimnech]

I once heard it said that progremmers should be forced fix their own bugs for a couple of reasons. First they will become better programmers because they learn from their mistakes and second the worst offenders have less time to inteoduce new bugs. A possible third benefit is that peer pressure may push them to do better.

[garyclouse]

It's harder to spot the bugs in your code than in someone elses

[captvimes]

I started out fixing bugs in production support at Amex as an 18 year old. I have been doing it so long peoplecome to me all the time because they know i wont dodge it. You learn so much from supporting other peoples code. I would recommend to anyone starting out to work in that area first as an engineer you wont regret it. If you dont fix stuff it is like being a mechanic that only builds new cars. I also always admit it when it is my bug.