LeetCode Problem Of The Day

Over the past couple of years I have adopted a habit of completing the LeetCode “Problem of the Day” each morning, often as the first thing I do when I wake, or at least before I start work. I love this and it has made me much faster and more confident about the type of algorithms and data structures questions that frequent software engineering interviews.

Technically, LeetCode calls these “[Month] LeetCoding Challenge [Year]” as the screenshot I captured shows. The idea is to solve each problem on the calendar day that LeetCode posts it, and build a streak of consecutive days that I’ve solved the daily problem.

LeetCode being a business, they also sell “time travel certificates” that allow me “travel back in time” to solve a past day’s problem and keep a streak alive. They also provide one extra weekly problem to paid subscribers. I believe you can’t technically complete the monthly streak unless you become a paid subscriber and solve those.

I don’t worry about the streak mechanic, although I certainly don’t begrudge LeetCode the attempt to generate some cashflow from the service they provide. Sometimes I miss days, either because of travel or family or because the problem is legitimately too hard for me to solve. I just pick up the next day.

One of my favorite aspects is reviewing the official Solution explanation, or the user-generate discussion thread, after I’ve solved a problem myself. I gain a lot from reviewing other users’ code and comparing their solutions to mine, especially when my solution works but is slow. LeetCode times submissions and shows the result, unless the code is so inefficient that it triggers a “Time Limit Exceeded” error.

The rhythm of solving one data structures and algorithms problem every morning is a terrific routine for programming practice. There’s obviously a lot more to software engineering than compact, competitive programming-style and interview-style challenges. But I always feel like a musician practicing scales or a basketball player practicing free-throws – hardly the entire repertoire of the craft, but nonetheless a valuable way to practice by myself and develop skills that translate to other parts of the domain.

Filming With Bjarne Stroustrup

I flew over to New York last night so that I could spend this afternoon filming with C++ creator Bjarne Stroustrup. It was so much fun!

Bjarne spent the afternoon answering so many questions about the C++ programming language. He’s incredibly amenable and gracious.

Udacity has an upcoming C++ Nanodegree in the works. Bjarne’s wisdom about the language will be an important contribution to explaining why he and the C++ standards committee designed the language to be the way it is.

C++ is the language of the self-driving car industry, and an almost mandatory requirement if you want a job working on autonomous vehicles.

If you’re excited to get started with C++ today, you should check out Udacity’s free course, C++ for Programmers.

Ford Invests in Pivotal

Along with the rest of the public, I learned this morning that Ford invested $182.2 million in Pivotal, a software consulting firm with offices worldwide.

I am super-excited about this partnership, although I confess I don’t understand the logic for investing in Pivotal as opposed to simply contracting with them.

But Pivotal is one of the leaders in the craft of software development and in Agile product development, and I think we can learn a lot from them that will make Ford a better place to build software.

In particular, I associate Pivotal with three great software engineering practices:

Pair Programming: Everybody at Pivotal works in pairs, even the non-developers. Two people, two monitors, two keyboards, two mice, one computer.

While some people view this as inefficient, I think it’s hyper-efficient. Most people subscribe to the believe that one great software developer is worth more than two average developers, and maybe more than ten average developers.

Well, pairing together two average developers is kind of like creating one great developer, or at least one very good developer.

Even better, the developers learn from each other and leave the pairing session better than they were when they came in.

Test-Driven Development: Test-Driven Development is the art of writing a software test, then writing the production code to pass the test, and then refactoring the code so that it’s clean. Rinse, repeat.

I have found this to be my favorite way of developing software — it makes hard problems much more tractable and bite-sized.

It’s also a great way to guarantee solid test coverage, much more so than “plain old testing”.

Agile Development: Pivotal is the creator of Pivotal Tracker, a service to track project development, milestones, features, and stories.

Having Pivotal Tracker is not, by itself, a replacement for product managers, but it’s a great tool, and cheaper and faster to get started than hiring a product manager.

Even when I’ve worked as a PM, I’ve found Tracker to be a terrific tool for building software products.