The Pragmatic Programmer

See the first post in The Pragmatic Programmer 20th Anniversary Edition series for an introduction. Challenge 1 Start learning a new language this week. Always programmed in the same old language? Try Clojure, Elixir, Elm, F#, Go, Haskell, Python, R, ReasonML, Ruby, Rust, Scala, Swift, TypeScript, or anything else that appeals and/or looks as if you might like it. Not long after reading this chapter for the first time, I started learning Clojure using Daniel Higginbothams excellent book Clojure for the Brave and True.

See the first post in The Pragmatic Programmer 20th Anniversary Edition series for an introduction. Challenge 1 Look at the software tools and operating systems that you use regularly. Can you find any evidence that these organizations and/or developers are comfortable shipping software they know is not perfect? As a user, would you rather (1) wait for them to get all the bugs out, (2) have complex software and accept some bugs, or (3) opt for simpler software with fewer defects?

See the first post in The Pragmatic Programmer 20th Anniversary Edition series for an introduction. Challenge 1 While reviewing a draft of the first edition, John Lakos raised the following issue: The soldiers progressively deceive the villagers, but the change they catalyze does them all good. However, by progressively deceiving the frog, you’re doing it harm. Can you determine whether you’re making stone soup or frog soup when you try to catalyze change?

See the first post in The Pragmatic Programmer 20th Anniversary Edition series for an introduction. Challenge 1 Help strengthen your team by surveying your project neighborhood. Choose two or three broken windows and discuss with your colleagues what the problems are and what could be done to fix them. I’ll discuss one example from work recently - exact details removed of course. Our current main project is the next version (3) of our main API.

See the first post in The Pragmatic Programmer 20th Anniversary Edition series for an introduction. Taking responsibility, in my opinion, is a large part of what contributes towards being a professional - as opposed to simply trading time for money. Furthermore, it not only applies to Software Engineering but to any profession and everyday life. Tip #4 (“Provide Options, Don’t Make Lame Excuses”) is especially applicable to Software Engineering. We solve problems, if the entire problem space was known already we wouldn’t have much of a job to do!