Discussion: Problem Solving and Learning on the Job as a Software Engineer

A while back several Revelers were chatting in Slack about learning and working as a software engineer. Some interesting ideas were being thrown around about programming problem solving and learning on the job, so we decided to record a discussion. What follows is a rough summary of some of the things we learned.

How does your educational background affect your programming problem solving approach?

Our group included folks who came from a traditional Computer Science (CS) background, as well as team members who were self-taught or got their start in a boot camp. The general gist was that the traditional CS curriculum is useful in specific circumstances but doesn’t really impart specific skills for learning and programming problem solving. In the university context, problem solving seems to be something that you’re supposed to pick up along the way. In contrast, Colin describes his boot camp experience:

I had no technical knowledge at all, and I came in very fresh. I was managing programmers, but I didn’t know what they did… and that’s basically what got me interested in it. It was Ruby on Rails with some HTML and CSS and, while we did learn a lot about the language and framework, the thing they really taught — that I thought made it effective — was how to learn and solve problems. Different methods for unblocking yourself, how to Google, questions to ask yourself when you get stuck to help you solve your own problem.

Colin

We heard similar things from all of our boot camp alumni, which is encouraging. This led to a discussion of rubber-ducky debugging —something everybody in the room gave credence to—though most of us don’t use any specific tool or format on a regular basis. 

The other notable takeaway was that those of us with a traditional CS background especially prized communication and soft skills learned in elective courses. We all agreed that these skills pay off as much on a day-to-day basis as any specific CS topic taught in school.

How do you search the internet for help with programming problem solving?

Hung and Deja both had good hints for using Google to solve programming problems…

• Paste in your error messages, but don’t expect an immediate hit on the whole message. It’s hard to decipher what’s specific to your machine, and what’s going to lead you to the essence of the problem. By searching on portions of the message, you’ll eventually get results that will help you, or lead you to other more helpful search terms.
• Start with general searches and get more specific to narrow down results: Sometimes a well-written article that explains the 10,000-foot view is more helpful than a mailing list archive that mentions your exact error message.
• Be patient and refine your vocabulary: You might not know the right keywords to use until after you’ve read one or two of those tangentially-related results.
• Sort by most recent: Things change very quickly, especially in certain rapidly-evolving ecosystems like JavaScript and Elixir.
• Don’t be afraid to go deep: Sometimes you do end up reading mailing list archives, GitHub issue comments, and community forums. If you limit yourself to tutorials or even Stack Overflow, you may be missing some key information.

One Reveler said that “Google is a double-edged sword for learning.” There are definitely risks—you might land on misleading or outdated info on the one hand, or you become a “cut and paste programmer” on the other. One suggestion was to just be aware of the fact that you came to the internet to learn what you need to solve your problem, not to have your problem solved for you. There’s plenty of useful code on Stack Overflow, but it’s only truly useful to people who take the time to understand it and adapt it to their own needs.

What about digging into your frameworks and dependencies?

These days, we often end up shipping a little bit of our own code alongside a whole lot of library code, so a lot depends on how that library code behaves in your use case. Often times reading the documentation is enough, but what can you do if that’s not cutting it?

Ruby Gems or Hex/NPM Modules are just code. If it’s not doing what you expect, crack it open and figure out why. You’ll learn tricks you didn’t know before, and you’ll be surprised how much better you are at reading code than you thought you were, and if you’re not… Well, now’s the time to learn I guess 😉

Adam

We talked about the fact that many libraries today have links to source code right in their documentation, which is fantastic. Participants also mentioned getting familiar with inspection tools like gem open for Ruby, npm repo for JavaScript, and the open/1 IEx helper in Elixir.

Adam also pointed out that you don’t need to be limited by the languages and frameworks you “know.” If the package you’re using or the code example in the docs is in a different language, go ahead and try to read it. The more you do it, the faster you’ll go and the easier it’ll be next time. With enough experience, you don’t really care much about the language.

When is it time to ask for help?

Daniel suggested putting a time limit on “spinning your wheels” on a programming problem, like a one-hour timebox. It’s not an admission of defeat, and it doesn’t mean you won’t learn. It means you’ll learn more, and more quickly, and your colleague(s) might learn something in the exchange also.

In addition to asking for help if you get stuck for a long period of time, just let people know when you start working on something new. Sometimes somebody will reach out to you and share something they know about the code or the problem domain. If you have just a little bit of a push in the right direction at the beginning, I think that’s hugely beneficial.

Daniel

Then there are those times when you’re chunking along very slowly, getting unstuck every 30 minutes only to hit another blocker right away. Though progress is being made, you’d still be better off with another pair of eyes on the problem.

Finally, Hung points out that you don’t have to reserve these syncs for times when you’re stuck and don’t know what to do:

Sometimes just talking with another colleague about the problem and making sure you understand it goes a long way. It’s possible you might not feel 100% certain you understand the issue and just need some reassurance. Maybe the code isn’t wrong but business logic keeps changing.

What about brain resets?

We’ve all spent way too long tracking down a silly bug or struggling through a hard programming problem by sheer force of will and determination. Aside from asking for help, it can also be really helpful to take a break to reset your brain. Some folks like to take a walk (perhaps with a pet), others prefer to read something (real paper books even). But everybody agreed that it should be something that gets your focus off the problem for a while and gives you a chance to come back with a fresh perspective.

Brain resetting is a real thing, and I do it a lot. I tell people my randomness isn’t always just random… sometimes it’s calculated. I’m moving around to try to get some brain resets going.

Bryan

What about more in-depth learning and continuing education?

Most of our group don’t regularly find time to take full-blown courses outside of work, as much as we might like to. Building “work-life alliance” is one of our core values, and we all have other demands during evening hours and on weekends. Luckily, our day-to-day work at Revelry provides plenty of interesting challenges and opportunities, and many of us learn best when we have a goal to achieve at the end of the day.

---

Deep Learning personal development programming bootcamp