[mgkimsal]

I'm not quite in the same age range, but north of 40, and have been doing this for > 20 years.

The tech changes - I don't use BASIC or Z80 machine code day to day. The skills that I can speak to, and the skills I see from others with this level of experience, are problem solving and communication, and secondarily the confidence that comes from having made mistakes. Few projects fail miserably solely due to technical issues and skill; in my experience failures come about because of poor communication (including documentation, but also speaking, reading body language, office politics, etc).

[madez]

We younger folks are incredibly curious about what you've learned. Can you elaborate on the topics you mentioned or recommend other sources? Can you give tips on best practices?

[mgkimsal]

Hrm...

Not sure I have any specific sources to share (others might) but after working with all types of hardware, languages, business realms and what not... you start to see patterns. Human behavior patterns, mostly; the same sorts of needs were there 30 years ago as are here today. People need stuff done yesterday, don't know how to describe what they want, oversold a client on something, etc. The numbers may be bigger, the gigahertz faster, and the memory far greater than people could have imagined, but the problems of translating what people say in to what they want via code is ... fundamentally still the same.

A 16k RAM module was ... $200 in my early days. Then a few years later I got 512k for only $150. Today I can get a 16 gig USB stick for $10, at at a local grocery store checkout aisle no less.

No doubt technology has changed and become more ubiquitous. Peoples' expectations of what's possible and what's normal are somewhat different today than 10-20-30 years ago, but the communication problems are still largely the same. Who's in charge of a project? What are the parameters? What defines "success"?

I'm not sure there's any real silver bullet here - most of the "mythical man month" stuff (from even before my time!) is still largely true (speaking in generalities because I can't think of every single line right now).

Learn to figure out how to communicate better - emails, phone, IM, paper, phone, f2f, etc - they all require different skills, and have different impacts on different teams.

Happy to answer more specific questions here or via email - [e-mail] - not sure if I'm just rambling now or not.

[narrator]

Back in the early 90s, I was doing mac68k programming. Very large Inside Mac volumes were pretty much the only documentation for anything - no stack overflow, no internet, no searchable docs. Almost everything was closed source, and many people wrote their own data structures. When programming Macs, if there was any kind of null value dereference or pointer problem the computer usually crashed and you had to reboot.

The main thing I learned was to be able to look at code and determine if it was going to actually do what I wanted it to do without having to run it through the debugger a couple times.

It's important to spend time thinking about and reviewing code when edit, compile, and test cycles start to get long. There are a lot of instances where that still applies, such as with multi-threaded programming, integration testing or long running jobs.

I also learned the value of having muscle memory for APIs. Sure you can look things up in a jiffy, but actually rote memorizing stuff that is used often can speed development up.