I have accumulated more vacation time that I’ll ever be able to take. For that reason, I decided to take the entire Thanksgiving week off. It’s nice to rest for a few days and catch up on sleep, but I won’t be producing any meeting doodles during this time.
This one is from a few days ago. It “appeared” on a page during a meeting. I have no idea what it is.continue reading
When I started coding in 1984, there weren’t many choices of languages and technologies. Basic, C and Pascal were the main ones. Only a few books on the topic were available, and the internet didn’t exist. With such a limited choice, it wasn’t difficult to decide how to spend my learning time to become a software developer. Distractions were not a problem, and networking wasn’t much of an option either.
Over the years things changed dramatically. Today you have an incredible array of options and information to choose from. Deciding where to spend your time can be daunting. Should you become a generalist, and know a little bit of everything? Or a specialist, and know one thing well? Also, should you learn to write code at all? Are you trying to start a business, or are you trying to learn to code? What are your goals? ...continue reading
You Need a Balance of Doers And Leaders
Every software engineering team requires doers and leaders. In my experience, for every five or six doers, you need a leader.
Engineering teams with too many leaders tend to fight about direction, vision, and control; as a result, they get very little done. The work environment is crippled by turf wars and constant attempts to reach consensus. Whatever they ship, ships late and looks and feels bland and designed by committee. Thankfully, having too many leaders is not a common situation.
Engineering teams with too many doers can’t stay on track and spend much of their time in technical disagreements, sidetracks, distractions and misalignment problems. Everyone makes decisions in isolations, and chaos reigns. The resulting software products feel like a collection of features stuck together with no vision and significant integration and usability issues. ...continue reading
This week’s doodle started with the small vertical cylinders and grew a life of its own as I was drawing it. Fountain pen, Noodler’s ink on Moleskine.continue reading
To be effective, software engineers must hone their problem-solving skills and master a complex craft that requires years of study and practice. Despite what newcomers might think, understanding a programming language, a framework or even algorithms is not the hard part of building software.
For example, languages are easy, especially the C-inspired imperative ones. There are only 32 keywords in the C language, and their meaning is easy to master:
C also has 14 pre-processor directives, which are also not difficult to understand: ...continue reading
I have been building software since 1984. Other than to my family, I owe everything I have today to the software industry, software engineers and the world of computers and technology.
A few months ago I decided to start writing about my experience and what I’ve learned. I started this blog and I have been enjoying the process of thinking and organizing my thoughts in the form of posts.
I tackle topics related to life in the software industry: technology, careers in tech, software development processes, engineering culture, and anything else that has to do with the people who build software and how they work. ...continue reading
This week’s doodle is another multi-day creation that started in the center of the page and expanded in all directions. I called it “boarded up” because it reminds me of a bunch of wooden boards nailed together.continue reading
Leadership is an art; this is not only a statement that I genuinely believe to be true, but it is also the title of an excellent book written by Max Depree. In his book, Depree gives us the following description of the responsibilities of a leader:
The first responsibility of a leader is to define reality. The last is to say thank you. In between, the leader is a servant.
These words echo in my mind quite often during the day. They have guided me time and time again when I felt unsure of how to add value. They also hold a profound message that can easily be missed: Reality doesn’t just “exist,” it is something that needs to be defined. ...continue reading
This doodle went on for several meetings throughout the span of several days. It started in the center and expanded outward. You can tell the difference in styles and patterns at the various stages.
Do you enjoy Doodle Tuesday? Let me know what you think.continue reading
Software Making is Just Starting
Building software is still in its infancy. Today we write a line of code at the time to describe what we believe a machine should do to resolve a problem. Developers spend most of their time sorting out minute details of behaviors. They do so to ensure that a task is executed precisely in a well-defined and understood way.
The unfortunate reality is that this method doesn’t scale well. The world needs software, but today’s software creation process is slow and complex. We’ve seen this in the past with other forms of art and craft. ...continue reading