Today I woke up wanting to start a discussion about what it takes to be an awesome software engineer. I constantly see recruiters evaluating candidates solely based on their programming skills. Hence, most developers focus only on learning the latest programming language out there. Is that all it takes? Here’s my two cents on the matter.

First, I’d like to mention that I have 12 years work experience and over those years I’ve moved from developing software, to mentoring others, to hiring new candidates, to coaching those people on how to form high-performing teams. What follows is based solely on my experience; it’s not my intention to present this outline as the only way to succeed. Heck, I still have a lot more to learn and might just change my perspective next month!

When I started my career, I was passionate about technology. Read tons of books about different programming languages, even more about abstract concepts like design patterns, and countless blog posts about specific subjects such as identifying the best approach for testing external services. You know how it is. There came a day when I felt pretty comfortable with coding and addressing the different problems I was facing and, even though I knew I still had a long way to go and a lot to learn, there was this small internal voice telling me: “You rock, man, you could even be considered a senior dev anytime now.” Little did I know that was only the beginning.

Our company was a pioneer in the use of Agile methods, especially Scrum and for the past 10 years, we have been practicing the principles behind the Agile Manifesto. We have always been convinced that it is the best way to add value to the customer and at the same time respect our own mindset. So we organized an internal training session to level out all WyeWorks employees’ knowledge of Agile/Scrum.

WyeWorks is officially celebrating its 10 year anniversary.

When we founded the company in 2008, we had very specific goals in mind: do quality work that would make us proud, surround ourselves with talented people, and build a team that would enjoy working together.

We chose Ruby on Rails and felt right at home. The community made us feel welcome, no matter where we were from, irrespective of our background and technical skill level. It was the perfect environment in which to learn to become better developers and make friends. The community and framework made it easy to adopt good practices and make them one’s own. We chose SCRUM because we believed it would allow us to put our values into practice, constantly deliver value, and continually improve.

We all know that modern applications can get very complex, very quickly. Because of that, I’ve been trying to add more automation to my daily life in general, as I know I’m human and will eventually mess up due to being distracted, tired, or something else.

One of the first things I did while on my automation journey was to figure out a way to automate the creation of cloud resources. In order to accomplish that, I became proficient at using Infrastructure as Code (IaC) tools such as Terraform and AWS CloudFormation, among others.

After that, the next logical step was to integrate that knowledge in infrastructure provisioning into the CI/CD pipelines, since I have (or try to have) CI/CD pipelines setup in every project I’m involved in. In this post, I will present the benefits of doing just that and will demonstrate it using a specific Terraform + CircleCI example.

This article tells the story of our experience implementing a shift in approach during the Daily Scrum meeting. We went from a typical approach centered on each individual to one centered on each story of the Sprint Backlog. The idea for such a shift was inspired by a Jeff Shuterland paper, one of those many great writings Jeff has produced throughout his career.

The goal is to briefly explain why and how the change was adopted; the strengths and weaknesses we observed; and feedback we were able to obtain upon having adopted such a shift in approach. But, before launching into explanation, it is important to provide you with the context of this experience.

A couple of months ago, I came to realize I might actually like DevOps. I wasn’t sure what to do, so I talked to the VP of Engineering at WyeWorks. Following that conversation, we found a way for me to work in a DevOps position for several months and try it out.

I left the project I was working on at that time and was given a month to learn some basic stuff so that I would be somewhat useful in a DevOps job. And that’s exactly what I did. Beginning January 2nd of this year, I’ve been reading up on and doing DevOps work 5 days a week, 7 hours a day.

In this post, I’m going to discuss my perspective on IAC (Infrastructure as Code), what problems it solves, and how it can be implemented. I will also share some resources for further learning, as well as briefly present Terraform, an IAC tool.

In the project I’m working on, I was given the task of investigating how to integrate Vue.js with our existing Rails app. So I started reading the official guide, watching tutorials and reading various posts until I finally got a fully working Vue component.

Finally it was time to write some tests, but unfortunately, the Webpacker gem doesn’t include testing configuration, so I had to do it on my own.

To my surprise, I found that there wasn’t much documentation on how to do the setup. So I figured I’d make this post to share with you how I managed to eventually get it working.

There was a time when I found myself constantly switching between my personal and work computers, and it was really annoying. After some time switching back and forth, I decided to use just one computer.

After settling on the single computer approach, what irritated me most was having to remember to switch my Git username, email, and SSH keys when moving from a work repository to a personal repository and vice versa. I would frequently forget to do that and, every now and then, I would find work commits tagged with my personal email or the other way around.

At work, most of the repositories are private, but at home most of my work is public, which means that my work email became public, and I didn’t like that. Hence, in this post I will share one way you can go about forgetting to switch back and forth and let the computer do it automatically for you.

Recently, I have been investing some time learning VueJS and I found that it is a very interesting framework to play around with. In fact, I have been working on a new project prototype for the last few days and wanted to show it to some people, so I wanted to publish it somewhere in the Internet.

I decided to deploy the project on Heroku so I started to research what is the best way to do it. To my surprise, I did not find much about it apart from a few posts like Quick-n-clean way to deploy Vue + Webpack apps on Heroku and Easily deploy a Vue + Webpack App to Heroku in 5 Steps. Nevertheless, I ended up with a different setup and this is the topic of this post.

If you have been developing software for some time you have probably noticed that there are lots of things that can go wrong, no matter how hard you try there is always something you might forget because after all, we are only humans doing an extremely difficult task: Telling a computer what to do.

In this post I will expose some of the git-hooks we use in some projects here at WyeWorks to make developers life easier by preventing bad commits to even leave their computers. I will cover linting, tests and commit formating use cases.