The Art of Developing Software

The below is taken from an interview conducted at the Computer History Museum in 2004 by Grady Booch. He interviewed early Apple developers Bill Atkinson and Andy Hertzfeld about the development of the original Apple Mac, and in particular MacPaint software.

On the art of developing software

Grady Booch: So what makes software beautiful for you? Do you care about the beauty of software?

Bill Atkinson: Oh yes, it’s an art form, like any other art form, and it’s not just practical, as in, does it do the job? Is it clean inside, does it look--? I would spend time rewriting whole sections of code to make them more cleanly organized, more clear. 

I’m a firm believer that the best way to prevent bugs is to make it so that you can read through the code and understand exactly what it’s doing, that there’s nothing tricky in it, that it’s all very straightforward. And maybe that was a little bit counter to what I ran into when I first came to Apple. 

There were a lot of people who prided themselves in how this little piece does something that I can’t for the life of me figure out what it is, but it’s magic that it does it. I would do things like deliberately assign something into a variable, and instead of putting ten operations concatenated onto one line, I’d use intermediate variables so I could understand the purpose of each of these. And I liked it. 

I found that if I spent time going over the code, cleaning it up, making it sometimes tighter – I did a lot of measurement and tried to make the performance good – but also making it so that it was straightforward so another person could follow in my footsteps, then I would feel proud of it.

Grady Booch: Don Knuth was telling me that he felt that MacPaint was perhaps one of the most beautiful programs he has ever seen, just in terms of its readability. 

On the MacPaint development process

Bill Atkinson: I had a different method of software developing than Randy Wiggington who was developing MacWrite. We had two different philosophies. Mine was you don’t get to add any new features until what you’ve got is working reliably, solidly; and his was, let’s add all the new features and then let’s debug them. I just think that that’s a bad way to do it because finding bugs is a very unlikely proposition. If you search really hard you might find half the bugs that are there, and the others are going to bite you and you just don’t know when. So I had a little more conservative approach to design.

Grady Booch: What you describe is very similar to what the Agile community speaks of these days; always have something executable through incremental development. And it’s very cool.

Andy Hertzfeld: Yes, yes, that’s really how the Mac was developed.

Grady Booch: You were the first Agiles. So by my count, or others, MacPaint was about 5,804 lines of Pascal and so on; 2,738 lines of assembly language.

Bill Atkinson: Plus all of the QuickDraw I’d built on top, because without QuickDraw you couldn’t do all that stuff.

Grady Booch: And pretty much everything had built upon QuickDraw.

Andy Hertzfeld: Yes.

Bill Atkinson: There were 70,000 lines of assembly language [in QuickDraw]. 

More reading
Computer History Museum: Oral History of Andy Hertzfeld and Bill Atkinson
Revolution in The Valley: The Insanely Great Story of How the Mac Was Made, by Andy Hertzfeld
Folklore: Anecdotes about the development of Apple's original Macintosh
BYTE Magazine (1984): An Interview: The Macintosh Design Team

Follow @dodgy_coder on X

Alternative to becoming a Full Stack Developer ... Become a Generalist

Starting out
When you're starting out your career as a software developer, you'll typically get a first role as either a backend or frontend dev, and after a couple of years, gain some experience on the other side to become a full stack developer.

Company specific lock in
Since every organisation has its own tech stack, a full stack developer in Company A will have a different set of skills than one in Company B. Those additional skills you learn are still useful to boost your knowledge - it can include: specific cloud services, CI/CD, containerization, DevOps processes, a domain specific library or framework, and the company's SDLC process. 

At this point many developers stay committed to their company's tech stack and remain working as a full stack developer for several more years. My advice - don't just coast as a full stack developer,  branch out!

Branching out
Don't limit yourself to web apps.. branch out as soon as you get the chance, by getting some experience with any of these (if possible as part of your day job)...

• Native mobile app development (Swift or Kotlin)
• Cross platform mobile app development (Flutter or React Native)
• Desktop app development
• A newer backend programming language (Golang, Rust or Elixir)
• AI & ML
• UI/UX design using a tool like Figma

Some other ideas (which might need to be in your own time)...

• IoT (Arduino or Raspberry Pi)
• Game development (Unity or Unreal)
• Blockchain development 

Become a generalist
Your aim is to become a generalist - someone who has deep knowledge in two or more areas and maintains a broad knowledge across many platforms, languages and frameworks.

After becoming a generalist, you'll be able to switch up your job roles, stretching your capabilities a bit each time you move. You'll find that you can apply for a larger variety of roles, increasing the possibility to land your dream job. 

Adapt to new roles
Your varied knowledge will make it easier to apply your skills in new and unfamiliar areas, building up after some years to become a senior developer. Once there, its possible to remain at the senior level for an extended period - as long as you still enjoy it and are still learning, why not.

Career progression
Eventually you might try for a tech team lead or software architect role. Software architects often started out as generalist developers who gained enough varied experience to be able to apply their software design skills into any domain. Tech leads can have a similar background, but they maintain more of a hands on development focus as part of their role, getting involved especially with creating proof of concepts. 

More reading
Generalist vs Specialist - the difference
Bill Gates on the book "Range: Why Generalists Triumph in a Specialized World", by David Epstein 
"The Polymath: Unlocking the Power of Human Versatility", by Waqas Ahmed
"Polymath: Master Multiple Disciplines", by Peter Hollins
What It Means to Be a Software Architect — and Why It Matters
Following the Software Architecture Career Path

Follow @dodgy_coder on X

Thanks to reddit user -NewYork- for this meme

Which .NET ORM - Dapper or Entity Framework?

Within the .NET ecosystem, two ORMs dominate, the lightweight Dapper (open source) and the fully featured Entity Framework (EF) by Microsoft. 

Depending on your project's size and requirements, either of these should work well for you, but there are definitely some known cases where each is a better fit. That's what we're discussing in this post.

When to use Dapper?

• Small to medium size projects. It has low overhead in terms of setup and configuration.
• The database tables are in place already and you're calling existing stored procedures. This is known as a data first approach.
• You prefer to hand code the SQL for speed, optimization or fine tuning.

When to use Entity Framework?

• Its a large and/or enterprise type project.
• The database hasn't been created yet and you'd like to use a code first approach. The framework will create the database for you after you code the data models.
• You want the ORM to handle transactions for you in the background.
• You need to use the power of C# LINQ (Language Integrated Query), whereby SQL joins and other queries are generated for you based on your C# code.

Other important factors

• Is your project likely to change frameworks, or need to be adapted to other databases? If yes I'd favour Dapper, because there's just less to migrate and configure. Dapper tries to not get in the way. There are no  additional abstractions and class models that happens with EF.
• Are you using .NET Core? Its probably a controversial opinion but I feel that .NET Core as a framework is still quite unstable compared to the original .NET Framework. So when a new version comes out, there's normally breaking changes within EF Core. For that reason I'd also favour Dapper over EF for .NET Core projects.

What's not a factor?

• Speed and performance. There's no longer any significant performance difference between Dapper and EF. Issues with performance are more likely to be something else that's not being done correctly at the SQL level, such as a lack of indexing, or an incorrect query.
• The origin of the framework. The first release EF for .NET which came out in the 2000s had terrible performance. Since that time, all the performance issues have been fixed.

Follow @dodgy_coder on X