How to get into Software Engineering as a student

Software development and technology move fast. It's an ever-changing landscape of different tools, platforms, and initiatives. With such a fast-paced discipline, I've been hearing questions from students wanting to get into software engineering, such as, "What are a few things I need to do in order to land a job with a team that's just as passionate as I am?"

Let's face it, being a software engineer is the hottest career right now. There's a war for talent where companies (startups and large corporations) are fighting over the best of the best software engineers that are leaders in their respective masteries (backend, frontend, mobile, games, etc). We're in an age where the cost of technology is so inexpensive thanks to cloud computing and continuously evolving toolsets. In addition to this, teams are now practicing LEAN. LEAN is a simple way of quickly testing viability and value proposition by shipping fast and shipping often. This means that there are no "perfect" products in the startup world and usually means that there are a lot of 80/20 approaches to solving problems.

Below are a few suggestions that can help in landing your first job when you're coming out of university:

1. Show up at meetups and expand your professional network

It's always great meeting new people and finding out who's really dedicated to their mastery. Meetups will often open the doors to these passionate people. The faster you're able to connect with people that love what they do, the faster you can start making a positive impact on the community by working with them on collaborative projects, technical talks,  and open-source initiatives.

2. Share your work on Github and continuously improve yourself as a software craftsperson

Part of being a leader means not being afraid of embarrassment. Every programmer can write terrible code but it's really up to them to take in that constructive criticism from their peers, improve, and push forward. Being open about your mistakes is a great way of showing a high level of maturity.

3. Make a name for yourself as a leader -- inspire others around you

Adding value to other people's lives can have a positive impact on your career path. People will always remember your acts of kindness and dedication -- going above and beyond the call of duty to help them, mentor them, or inspire them.

Cheers,

Jaime

Autonomy, Mastery, Purpose -- Software Engineering

Software engineering is hard. We all know from a technical perspective, we hit our heads against the desks trying to figure out solutions to problems that have the most constrained environments and it's up to our ingeniousness to think outside the box and solve it. This is why I love software. In today's blogpost,  I won't be talking about the technical aspect of software engineering but the human side: team building.

The next generation software engineering companies that create the most interactive, engaged, and fun environments will be built on top of 3 core concepts: autonomy, mastery, and purpose. This is a widely used phrase and it's evangelized by Dan Pink. In his book, "Drive", it dives into the problems of current working environments for software teams but then it goes into a few studies and examples of how to evolve the working environments to create teams that know how to hustle, have fun, and drive value to their customers.

Valve, Github, Atlassian, 37 Signals -- all great examples of teams that know how to hustle, think outside the box, and ship amazing products that provide a solid amount of value proposition.

Why does autonomy work? At the core of autonomy is self-direction. A teammate has the ability to take the reigns of a project and apply their own creative thinking to solve a customer's problem. Human beings naturally want to build ... things. We're made to be creative -- our minds are so expansive. We've put a man on the moon, we've created microprocessors which can calculate results in milliseconds on extremely large data sets, and we've created medicine that heals people's pains. With such an incredibly valuable tool (the mind) to the human anatomy,  the question isn't "why does autonomy work?" it should be, "why do we hire managers to tell smart people to sit down, shut up, and code XYZ"? Self-direction is the result of a teammate having an amazingly positive attitude, the willingness to learn, and the initiative to take ownership and get things done.

Mastery is another core aspect of motivation. Mastery can be defined as the level of subject-matter expertise one has in any particular topic whether it is sales, engineering, or user experience. Adding to that, having a level of expertise also is complimented by the attitude to consistently keep learning new things -- getting better through practice -- constantly evolving and improving.

Purpose is the drive towards accomplishing the mission. Having a team with shared vision -- with a purpose to ship an amazing product -- is the most satisfying and exciting feeling one can have. I always like to think of this as an NHL team putting their hearts and souls into winning the Stanley Cup.

The management styles of the 1900s which are militaristic, iron-fist, and hierarchical will die off at an internal level (there's political sides to "showing" that you have hierarchy for example to investors) to make way for a much more humanistic, evolved, and scalable solution that obviously puts the team, customer, and product first -- not hierarchy. It is becoming widespread and it's clear that software engineers prefer the freedom to create: to experiment, take ownership, and drive value proposition in their own way than have a fancy title and a large office.

The Cost of Continuous Delivery

Continuous delivery is a process in which developers can land features on master (or trunk if you're on subversion), have it run through continuous integration (unit tests, user interface tests, service layer tests), have it propagate through the various stages of your deployment pipeline and have it on production in short matter of time. It sounds great because you'll never really need an ops team anymore and really dispels the need to have iterations (in 2 weeks, a feature lands, instead, a feature lands when it lands).

A build pipeline like that saves money for the company in that respect and makes it so that engineers can react more quickly to problems without having to go through layers of communication; however, it surfaces many more issues. As a software engineer on a fast pipeline that is continuously delivering to customers, it is increasingly more important to have test coverage. Below is a list of aspects of testing that need to be seriously thought of

• Unit Testing
• Web Service Testing
• User Interface Testing

Taking a step back, in order to really take continuous delivery seriously, we should always look at the true value of having automated tests. Here are some of the core principles of automation testing:

• To protect our users from misbehaviours in the system (never cause distrust between the product and the customer)
• To be vigilant on any changes to the source tree (new and legacy code can be fractured easily)
• To be able to verify functionality in an automated fashion without increasing engineering manpower (reducing costs -- people are the most expensive aspect of running a business)

With the above, automated tests in a continuous delivery model should now a part of the feature itself. Without tests, it is not a feature and it should not be able to land on production as it would be too much of a risk to the product and the customers. The most difficult part of absorbing the cost of continuous delivery is convincing the stakeholders that the new model is faster but needs more checks along the pipeline. This cost of continuous delivery (Jidoka) includes

• spending time writing unit tests
• spending time writing service layer tests (assuming your platform follows SOA, validating inputs/outputs of data)
• spending time writing user interface tests that detect defective user flows (registration, updating profile, etc)

In the end, following the guiding set of principles of Jidoka allows your engineering teams to produce high quality features by detecting defects along the pipeline and ensuring there's fixes in place to keep the pipeline pushing forward.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software engineer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Bacardi, Nike, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's writing open source software and helping developers in the Windows Azure NodeJS community.