Software Craftsmanship

Company’s mission is to support the process of designing, creating and deploying software in corporations and public institutions, to minimize cost, time and risk associated with these endeavours.

Great designers design, that’s why they’re so great.

In one way or another, all professionals practice. They do this because they care about doing the best job they possibly can. What is more, they practice on their own time because they realize that it is their responsibility – and not their employer’s- to keep their skills sharp. Practicing is what you do when you aren’t getting paid. You do it so that you will be paid, and paid well.

Computer programming, like any creative activity, demands constant study and practice. Vladimir Horowitz practiced the études of Chopin every night, after he performed a concert, to maintain his skills for the next performance. Tiger Woods drives a thousand balls on the driving range, every day. Pablo Picasso sketched a bull ten times before the eleventh bull was right.

Throughout my whole career I never had to use scripting. Not even once.

You will not use multithreading in a true business software.

A kata typically refers to fundamental movements in Japanese martial arts, but can refer to any basic form, routine, or pattern of behavior. Recognizable patterns of behavior and clear expectations make it easy to recognize abnormalities (problems) and also serve as a basis of improvement, setting and attaining higher standards.

In lean management, kata refers to two linked behaviors: improvement kata and coaching kata.

Great designers design, that’s why they’re so great.

Code Retreat is a fun exercise. You meet a bunch of strangers and friends alike, mix with them for a 45 minutes pair-programming and try to solve a simple (deceptively!) problem in a TDD manner.

Code Retreat is a fun exercise. You meet a bunch of strangers and friends alike, mix with them for a 45 minutes pair-programming and try to solve a simple (deceptively!) problem in a TDD manner.

So, you code a lot and…​ you learn a lot. Different IDEs, different languages, different versions of Java, different testing frameworks, keyboard shortcuts, etc. etc.

The exercise is famous enough to have its global edition, every November. Hence - this meeting.

Aside from the first (two?) session(s?) each session will have its unique constraint, to make things more interesting. :-)

I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. This has been brewing since April, and is starting to get ready. I’d like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).

If you can’t explain something to a first year student, then you haven’t really understood.

Practice Drill #1: Write your resume. List all your relevant skills, then note the ones that will still be needed in 100 years. Give yourself a 1-10 rating in each skill.

Practice Drill #2: Make a list of programmers who you admire. Try to include some you work with, since you’ll be borrowing them for some drills. Make one or two notes about things they seem to do well — things you wish you were better at.

Practice Drill #3: Go to Wikipedia’s entry for computer science, scroll down to the "Prominent pioneers in computer science" section, pick a person from the list, and read about them. Follow any links from there that you think look interesting.

Practice Drill #4: Read through someone else’s code for 20 minutes. For this drill, alternate between reading great code and reading bad code; they’re both instructive. If you’re not sure of the difference, ask a programmer you respect to show you examples of each. Show the code you read to someone else, and see what they think of it.

Practice Drill #5: Make a list of your 10 favorite programming tools: the ones you feel you use the most, the ones you almost couldn’t live without. Spend an hour reading the docs for one of the tools in your list, chosen at random. In that hour, try learn some new feature of the tool that you weren’t aware of, or figure out some new way to use the tool.

Practice Drill #6: Pick something you’re good at that has nothing to do with programming. Think about how the professionals or great masters of that discipline do their practice. What can you learn from them that you can apply to programming?

Practice Drill #7: Get a pile of resumes and a group of reviewers together in a room for an hour. Make sure each resume is looked at by at least 3 reviewers, who write their initials and a score (1-3). Discuss any resumes that had a wide discrepancy in scoring.

Practice Drill #8: Listen in on a technical phone screen. Write up your feedback afterwards, cast your vote, and then talk about the screen with the screener to see if you both reached the same conclusions.

Practice Drill #9: Conduct a technical interview with a candidate who’s an expert in some field you don’t know much about. Ask them to explain it to you from the ground up, assuming no prior knowledge of that field. Try hard to follow what they’re saying, and ask questions as necessary.

Practice Drill #10: Get yourself invited to someone else’s technical interview. Listen and learn. Try to solve the interview questions in your head while the candidate works on them.

Practice Drill #11: Find a buddy for trading practice questions. Ask each other programming questions, alternating weeks. Spend 10 or 15 minutes working on the problem, and 10 or 15 minutes discussing it (finished or not.)

Practice Drill #12: When you hear any interview coding question that you haven’t solved yourself, go back to your desk and mail the question to yourself as a reminder. Solve it sometime that week, using your favorite programming language.

This blog publishes new programming exercises weekly, at least, so that savvy programmers can maintain their skills by working the exercises and thinking outside their normal skill set, whatever that is.

To maximize gains from long-term practice, individuals must avoid exhaustion and must limit practice to an amount from which they can completely recover on a daily or weekly basis.

A number of training studies in real life have compared the efficiency of practice durations ranging from 1-8 hr per day. These studies show essentially no benefit from durations exceeding 4 hr per day and reduced benefits from practice exceeding 2 hr (Welford, 1968; Woodworth & Schlosberg, 1954).

Many studies of the acquisition of typing skill (Baddeley & Longman, 1978; Dvorak et al.. 1936) and other perceptual-motor skills (Henshaw& Holman, 1930) indicate that the effective duration of deliberate practice may be closer to 1hr per day.

How does the average guitarist practice? In the years before I started getting serious about lessons, I played a lot — 6 to 8 hours a day for about 5 years. I learned a lot of songs, all by memorization, and I had to play them constantly to keep them in memory, so at least 2 hours of every day was wasted just running through the pieces. Through brute-force effort I eventually started to sound like I knew what I was doing. Fooled myself and most of the people around me, anyway.

I felt I could muddle through almost anything, but it was clear that I became progressively sloppier as the music became more technically challenging. And there were some things I just couldn’t play.

The problem was that I had no idea how to practice correctly. The saying "practice makes perfect" is inaccurate, as any music teacher will happily tell you. Perfect practice makes perfect. I’d been practicing sloppily, and had become very good at being sloppy.