Tag: Development Teams

Microsoft: Welcome to Your New Future!

Microsoft logo

2020 has been an interesting year for everyone, without a doubt. For me, 2020 involved a career change that wasn’t something I was expecting at the start of the year. I had been comfortable with my past employer, Magnet Forensics, for just shy of 8 years and had the opportunity to work on many high-impact projects as part of a mission to help with saving children and assisting law enforcement. But at the end of August, I started my first day in my next adventure with Microsoft.

I wanted to write a couple of posts about getting up and running at Microsoft so I figured I’d start with some high level points. This post will be focused on what it was like to join a tech giant after helping scale a startup to hundreds of people internationally.

Meeting the Team and Colleagues

My hiring manager at Microsoft had a list of people he thought would be great for me to reach out to. Forerunners would be the team I’ll be managing and then connections for different functions I would be interfacing with. As well, the list included complimentary teams we’d be working with. Coming from a place where I had the luxury of being around since the beginning of the engineering department, it was a new experience for me to be the outsider… However, this list of initial connections was a great way for me to get oriented.

And well if you didn’t know… Microsoft is big. Really big. So this was an extremely intimidating experience for me. But as soon as I logged into Microsoft Teams I got a message from one of the engineering managers that interviewed me. And I mean literally as soon as I logged in because I didn’t even know where the notification sound came from! And it was an incredibly welcoming message that stuck out to me because this reinforced with me that I wasn’t just a number in a hiring process to fill a seat. Shortly after, I received a message from an old university friend on Microsoft Teams that was congratulating me on my new role and welcoming me to Microsoft. I could feel the tension easing up as I was feeling like I had some great connections already.

So I started sending out the emails to introduce myself and of course it felt awkward saying “Hi I’m the new guy… I know you’re super busy but can you set aside some time so I can get to know a bit more about you and how we’ll interact?” But you know what? Every single person was enthusiastic to welcome me and get something put in our calendar to chat further. Every. Single. One. I haven’t felt so welcomed before. Just another big-tech-stereotype that I had demystified for myself and I couldn’t be happier about it as I started my first day.

Microsoft: Consistent Values

Having not worked for a “big tech company” before, I think that like many people that have lived startup and small business life I made a lot of assumptions about what things might be like. After all, Microsoft has been around since… forever! I’ve been using Windows and Microsoft products since I was physically able to use a computer (which if you took a wild guess was at a very early age). We all know big tech companies only have small pockets of really awesome people… and everything is super corporate with a million layers of bureaucracy… And everything feels like a battle against “the system” just so you can get your opinion heard and….

Okay, so none of that was even remotely close to true. And it was VERY obvious from day one that through *all* levels that there is a homogeneous mission and vision. When the CEO talks about diversity and inclusion and then you see it coming up in the training, and coming up from different levels of leadership, and then directly in your conversations with peers ALL within the first couple of days… You know Microsoft has done something right to nail culture.

This is simply one example that I’m using that I feel would probably hit home with many of us, and I share it because while I could speculate that big corporations might just say they want to focus on this kind of thing in a media or press release, I was shocked (in a positive way) just how much emphasis is put into something that the company believes is a priority. Especially at the scale of the organization. These company-wide goals to focus in certain areas penetrate all levels of the organization and in such a way that you don’t feel “forced” into it, but rather you feel empowered and motivated to be part of the solution and have an influence in it.

Wrapping Up

I think that everything I had hoped was true from my initial talks with the recruiter right through to interviewing with the team was proven to be true right from my starting day at Microsoft. My fears of big-tech-bureaucracy and stagnated perspectives of a behemoth company (and actually more on this to come!) were shut down right away. All of this was such reassuring news as I was getting set up.

While switching companies in tech might not feel like a big deal to some people, for me this has been a completely different life path, and as I mentioned at the start it wasn’t one that I could have easily envisioned for myself. In my previous role I was challenged. I had responsibilities and expertise. I was part of an incredibly important mission. I managed teams of people I loved working with and had colleagues I’d consider to be some of my best friends.

But I was also comfortable. And on that note, I’ll be discussing why I believe that Microsoft is the perfect opportunity for me to challenge myself and help take on a growth mindset.


ProjectXyz: Why I Started A Team For My Hobby Project

ProjectXyz - Why I Started a Team

Who Needs A Team?!

I’ve been building RPG backends for as long as I’ve been able to code. I think my first one that I made for my grade 11 class is the only RPG that I “finished”… It was text-based and all you could do was fight AI via clicking attack, buy better weapons, level up, and repeat. It was also 10000 lines of VB6 code and so brutal that I couldn’t add anything to it without copying hundreds of lines of code.

Since then, I’ve had the itch. I keep rewriting this thing. I keep taking “Text RPG” (super cool and catchy, I know) and rewriting it. I had my first visual representation of this game called Macerus (here’s another rewrite for unity), which is actually how I landed my first co-op job. But every time I’d get so far, I’d decide I needed to rewrite it because I had messed up the architecture in some way and refactoring would be too much work.

My latest attempt is called ProjecyXyz, because I can’t come up with names. And funny enough, I just Googled it while writing this article and there’s actually a company with the same name… So maybe I’ll have to get more creative. ProjectXyz is supposed to be a very generic RPG game framework that allows new systems, mechanics, and game content to be dropped in, in addition to being independent of a front end for rendering.

It’s also something I’ve been making on my own. Because I’ve been making RPG backends on my own for years now. So who needs to have a team, right?

Too Much Pride For A Team

I think initially I wanted to do this all on my own because of pride. I also don’t think it was something I was conscious about except for the fact I looked at this project as my baby and something I could control the development of. I wasn’t consciously telling myself “I have to do this on my own so that I’m better than other people” or anything silly like that.

But why would I go ask others for help? They don’t code like me. They don’t have the same investment into this idea as me. They aren’t as passionate. They might have their own ideas for how to do things too! How could I have someone like that working on MY project?

Those are all pretty naive reasons for considering to work alone though. Sure, this is my pet project and I’m going to likely feel more attached to it than anyone else. That’s probably expected. It doesn’t mean that I can’t find people that are super interested in working on something like this. They could be totally passionate about learning different aspects of creating an RPG backend.

As for having their own ideas… That’s probably one of the BIGGEST reasons in FAVOUR of having a team! It’s easy to get scared about having other people put their ideas into something you feel like is “yours”. It might have taken a few years of working in the industry (currently just passed 6 years of working at Magnet Forensics), but it’s actually very common for other people to be contributing ideas into code bases you’re working on. It happens every day. Sometimes you have design meetings or code reviews or general architectural discussions and your idea ISN’T the one that’s picked. That’s cool! As long as everyone is striving for extensible and testable code, we can make changes if we need to going forward. You don’t need to make every decision and sometimes it’s much better that way. Other people are smart too 😉

Passion is Key for a Team

While the “team” I started isn’t an official team, it’s the first time I’ve been very open to having people directly contribute to my pet project. I think one of the most obvious reasons I became comfortable with this is because I found someone that was very passionate about exploring this space.

My colleague and I were talking about some of the concepts in ProjectXyz and where I wanted to go with it. Immediately he expressed interest in map generation and how that’s always been something he wanted to explore. How can maps be procedurally generated? Can we take this concept and generate maps on the fly? What are memory and runtime constraints? How do we represent this information in code? What about persistent storage?

I could immediately tell he was very curious about how a system like this might work. After several conversations with him about how he was starting to hack up some ideas and doing research on different algorithms, I knew he was passionate about it. We discussed working on some of these things together and contributing to the project code that I have, and we’ve been going back and forth for a few weeks now sharing ideas and his progress that he’s making for map generation. I’ve been hands off only really acting as a sounding board for him.

I think having someone passionate like this is critical for a small team. There’s going to be many barriers when working on a challenging project, and it’s easy to get bogged down and lose motivation when you’re stuck. Having additional people that are passionate about seeing progress in your project means you have some support for pushing through those hard times when you might lose motivation. If my colleague comes to me and says “I’ve been stuck on this issue and maps wont generate how I want…”, then I’m more than happy to sit down with him and talk through his algorithm and maybe where there’s an issue. I’m invested in seeing his piece come to fruition. Similarly, if I’m working on something like dynamic item generation for the game and I get stuck, I know he’s there to do the exact same thing. We both want to see this thing working how we intend.

So passion is important for a team. But is it sufficient? Is it the only requirement for adding a team member?

A Team is Built on Trust

Trust! Trust is a huge part of establishing a team because you need to be able to rely on each other. As mentioned, my colleague is passionate about working on this and has an interest in map generation. But what if I had never seen any of his code before? What if I didn’t know if he’s had practice with writing extensible code, testable code, following good design practices, etc… What if?

To be honest, I probably would be pretty nervous about him contributing code. It might be a huge barrier for me. I’d want to review his code and make sure it wasn’t “polluting” my pet project. I’ve re-written this code enough times that I really don’t want to have to think about rewriting it again! If I was nervous about someone contributing code I was going to need to re-write from scratch just to have an extensible design, it might not even be worth it having them contribute in the first place. It might actually create MORE work in the long run. It sounds selfish, but if the goal of adding someone to the team is to provide a net positive effect, then having to re-write code that isn’t up to par might be a deal breaker.

But that’s not the case here. I have multiple years of experience working with this colleague closely on various projects. We align to coding practices but still have our own twist on things. We value the same things in “good” code (extensible and testable). We use many of the same design patterns in similar situations. I’ve seen enough of his code to know that most of the time my comments about it are “oh, have you considered” and not “… you need to rewrite this”.

I can trust that what he wants to contribute will be aligned to my vision. I also can trust that new ideas he introduces are probably awesome new perspective that I hadn’t thought of. I also trust that if we disagree on something, we’re open to discussing it and coming to a resolution. So trust in this case certainly removes the barrier to entry to adding additional people to my hobby project.

Should You Form a Team?

While this was a pretty general article, I just wanted to get you thinking about opening up your hobby project(s) to other people to contribute. This is something I wish I would have considered more seriously early on. Maybe I wouldn’t be re-writing my project for the millionth time!

Some general points:

  • You’re not a “worse” programmer for getting other people contributing. Good programmers need to be able to work with others!
  • Other people can have good ideas too! Sometimes, they’re even better than your own ideas 😉
  • Other people may have more knowledge or interest in areas that need to get work done that you just don’t want to do! Perfect!
  • You’ll want to try and find people passionate about working in the area your project focuses
  • You’ll want to find people that you feel like you can trust so that you’re comfortable with them working on “your baby”
  • Getting help doesn’t mean your code must be “open source”. You can still share private repositories together (i.e. consider BitBucket!)

So what do you think? Is your hobby project kind of stale because you’ve hit enough roadblocks and it’s time to get some more firepower to tackle it?

Share your thoughts below about your experiences with forming teams for your hobby projects!


  • Subscribe to Blog via Email

    Enter your email address to subscribe to this blog and receive notifications of new posts by email.

  • Nick Cosentino

    Nick Cosentino

    I have nearly a decade of professional hands on software engineering experience in parallel to leading multiple engineering teams to great results. I'm into bodybuilding, modified cards, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress