Showing posts with label career. Show all posts
Showing posts with label career. Show all posts

Monday, November 9, 2015

Last and First Day with the Microsoft Band SDK Team

Well, for those that don't know, I have been working at Microsoft for the last 1.5 years as a contractor on the Microsoft Band. I have spent that time with the Microsoft Band SDK team and helped with test automation and testing first. Then I moved into feature development on the Band SDK with the majority of that contribution on the Microsoft Band WebTiles for iOS feature.

Friday was my last day as a contractor at Microsoft on the Band Team.

Today, Monday, November 9, 2015, as you read this I am likely sitting in a New Employee Orientation session. Today is my first day as a Full Time Employee at Microsoft.

I am staying with my team and will be continuing to contribute to the Microsoft Band SDK Team. I will be helping to implement upcoming features and continue to improve the Band SDK for 3rd Party Developers.

It's an exciting day. I am happy to join my team as a Full Timer and continue to improve the Microsoft Band.

Thursday, September 25, 2014

Describe yourself in an eye-catching 150 chars or less

I just applied to a full time position that wanted me to describe what makes me unique in 150 characters or less.

Here's my shot at that:
I've flown a plane with an electrical failure at night, watched life float pass pinned to the bottom of a river, and I still got the job done.
I've written about the night flight electrical failure in an earlier post. The river story is for another day ;-)

MT 

Wednesday, August 27, 2014

I Have to Hire an SDET (Software Development Engineer Test) for iOS, What Should I Ask?

One, of many, of our beach rock finds.
This was the question I got a few weeks back when an acquaintance from Xcoders messaged me to say he had to interview an SDET, for their iOS product, later that day. He did not know what to ask and what areas he should ask them to dive into. Did I have any suggestions?

So, over Twitter I gave a couple quick ideas on what to ask.  Here is that list, expanded a little.
  • What frameworks have they used to test iOS?
    • Compare the differences between those frameworks.
    • Go review this answer on stack overflow about iOS Testing. This will give you a rundown of the testing frameworks and tools for iOS.
    • What are the pros of those frameworks? What are the cons? And the next question...
  • Have they done UI Automation testing? How? What were the results of that testing?
  • How do they manage their tests? It should be better than I don't. Tools used to track the tests to know what coverage you have is essential.
  • How do they report on them? Not much good doing tests without being able to report on the results.
  • What are the different granularities of tests and how have they used them in past positions? Which do they find the most useful for iOS?
    • Unit Tests
    • Functional Tests
    • End To End Tests
    • UI Automation Tests
    • Manual/Adhoc Testing
  • What difficulties have they had testing iOS?
    • Or maybe the more blunt; What have they found to be unsuccessful or not of value when testing iOS?
    • Ask this since it might highlight the one area you want to concentrate on they might hate.
  • I have seen testers write great and sometimes not so great bug reports. 
    • How do they log a bug? 
    • What information is important? 
    • They should have an opinion on what to include.
  • Most iOS apps use a web service back end of some kind. How do they test the results of web service calls?
    • They should be saying Charles (or alternative packet sniffer like WireShark) here and using a proxy to sniff the HTTP packet flow.
  • Whiteboard time
    • Give them a simple method (Objective-C based please), just the definition and what the method is supposed to return.
      • For example, something that takes a string and returns a sorted array that includes each unique word found in the string. I just has to be complex enough to cause them to write several examples.
    • Ask them to write testcases for this method.
    • Do they know the syntax of Test::Unit style or RSpec style?
  • Can they program? If not, then you don't want them as an SDET. The whiteboard coding question should be a breeze for them.
  • Do they know scripting languages? Ruby? Python? Javascript? 
    • They should since the tools built on top of Apple's iOS testing frameworks are normally written in a scripting language.
    • They will also need to integrate tests with build systems which means command line knowledge and the ability to script command line jobs.
That was the short list I came up with with some additions once I expanded on the brief Twitter exchange.

Anything else you'd look for or ask?

Monday, August 25, 2014

Is Contracting For You?

I have not answered that myself and as such I am asking myself that question. I certainly like the fact I am working on new things and getting to branch out into areas I might not normally get a chance to work with. That said, there are some downsides as well.

At first you are going to see that hourly rate and say, wow that is a lot per hour. Hold on there though. Most likely that rate does not include paid holidays or vacation time. So you need to take your salary/year based on 40 hour work week (if your contract is 40hr/week) and then minus the vacation time you'd like to have and the holidays you won't get paid for. Check up front to find out if you can work holidays. If you can't, each of those days off is 8 hours of pay you are missing.

That adds up to make your hourly rate start to not look so good.

The other thing to consider about your rate and contracting is are you going to go with a firm (I have) which makes finding contracts easy but eats into your rate. Meaning, that the contracting company is taking a cut of the rate per hour you are being paid. Now, you don't see that taken out of your pay cheque, but needless to say, if you want to do the harder path and run the business side of things then you can make more contracting on your own.

Also, do you want to gain ownership of something and make decisions about the design and direction of the product? Then contracting, unless it is an architectural position, may not be your thing. So far I have seen that contractors in general are paid to get stuff built. That is great if you don't want to have ownership and just like doing new things each day. Not so cool if you like to have a say in the product and help design what you ship.

I am still out on this one. There is certainly an advantage to just being a grunt, getting stuff done. It is amazing to see the amount of code/progress you can make each week just implementing and not planning. That said, it's nice to have some more skin in the game with the design of a product.

Some other things to keep in mind is that you (most likely) will not get matching contributions for retirement or other benefits. That is fine if you are getting paid a high enough rate. If not, then you are missing another chunk of cash.

Contracting has the allure of new projects, less maintenance of products, and the ability to make more hourly. The truth is that the new projects and less maintenance of long term code comes at the price of ownership in the product. The high hourly rate hides the visible benefits of full time positions that you might not consider.

So, like many things in life, it all comes downs to tradeoffs. Which ones are you willing to make and what do you want out of your job.

Tuesday, August 5, 2014

The Illusion of Expertise

Replacing a section of my front
step. Definitely not my area
of expertise.
How much time does it take to become an expert with a new thing?

Let's pick a language.

I mentored a Junior Engineer on a work term who did some Perl development for our project. He then applied to work with us full-time when he graduated. Hey, I must have done something right to have him want to come back.

When reviewing his resume he had listed Expert Perl Knowledge or some such phrase. He wrote 2 scripts for us based off of scripts I had written. I asked him in the interview if he had done more with Perl after we introduced him to it. Nope.

Expert level knowledge? Sheesh!

As a professional developer I get asked to solved problems I have no idea how to solve every day. It's par for the job.

This is no different than many jobs I am sure. I know I have asked building contractors to build or fix something that they've never built or fixed before. So as a professional your expertise comes from being able to tackle these problems without fear. I am paying them for their past experience and ability to successfully deliver; same goes for being a software developer.

What do I mean by without fear?

I have worked with people that say they can't do something since it is outside the realm of their experience? They are asked to add some new functionality to an existing app or script and they say they can't, they don't know that language. I think this is the wrong attitude.

As an Expert, you are expected to step up and say, "Sure, I don't know that language but the program is already written and it just needs some small changes. I can take that on and learn a bit about the language it is written in at the same time. Thanks."

That's how I like to approach tasks outside my realm of Expertise. With contracting, this has become something I have to say more often. Does it slow me down to learn a new language? Sure, I don't know it off the top of my head but with the wealth of information on the web and help within IDEs, there is no reason not to jump in and try out a new language.

If you think you need to be trained in a language or domain to work in it, then you are missing out on being more useful to your team. Being willing to jump in and work in any language is a plus for you in your career that will make you more valuable as an employee.

Don't fear your lack of expertise. Dive in and take on challenges. You grow more from them than staying in your comfortable shell.

Monday, July 21, 2014

Sometimes You Just Have To Get Your Hands Dirty

Hockey Tweet in Landscape iPhone 4s (Landscape
was not in the original)
I have dropped off the radar for a bit as I have been busy with some projects. I took a week off from everything but code as I worked on porting my old 2009 Hockey Tweet app to Swift. I have written about that and will some more as I have major updates.

I was also studying for some interviews I had. One was an all day affair with a 7 hour interview that included a 2 hour pair coding session. We are still talking and no news yet to report on the job.

Outside of that I have been ramping up house work. For several reasons, I might have to sell my house (job), the house needs a new paint job, the deck needs a new paint job (or I will be replacing sooner rather than later), and of course I have all the prep work to do (caulking, 15 tubes Sunday) to even begin to paint.  Sunday I got a solid 8 hours in of caulking and then painting.

I started the painting so that I can begin alternating between caulking and painting. Since they use the hand and arm muscles differently, once I get tired with one I can switch to the other for a while. I also have over half of the house caulked now and wanted to get the front of the house completed. I figure I can do the front first and then continue the back of the house into the fall. Since you won't see if, you won't notice it is half/not done.

So, it's been a week of getting dirty. Dirty with new code as I learn to program in Swift. Dirty with house work.

Now some may ask, why not pay someone to paint your house? Heck, I wish. But at a $25,000 average quote to paint the house including prep work (some would not include prep since the amount of caulking was so daunting); I am sucking it up and being a man (frugal).

This just means I might have less posts for a while since how many blog posts can you do about painting you house? Who knows, but I am sure we will find out ;-)

Friday, July 4, 2014

Programmer Career Development: Always be Learning

I am sure this comes as no surprise to most programmers but here is how career development works in the field of programming, as I know it. The short story is, if you are not developing yourself then you are putting yourself at risk if the axe comes, the next job will be harder to find and you will be several steps behind when you have to retrain.
Image from HockeyTweet, the
1st iPhone App I wrote to teach
myself iOS programming.
I spoke to a fellow programmer recently who got cut from his full-time job and started contracting. He does not contract out of choice but out of a need to earn for his family. He was in one field for many years with a large company, they retooled their business to eliminate an obsolete product and his skills were no longer needed. His skill set was obsolete.

He related that when you get older people do not want to hire you as much. But when I listen to his story I hear someone that did not keep up with the changes in technology and the programming skills required to be current for today's jobs. He was blaming age for what was really a skill set issue.

I completely disagree that age is the issue. I think skill set and engagement in your field of choice is the issue.

If you are engaged in your field, are taking time to train yourself in the new technology/languages/processes, then your past experience is an asset to add to your "current" skills. Your past is not a detriment, it's a wealth of experience. Let's admit it, the hot languages change, the platforms change, but the skills to be a good programmer do not. We are still reading and learning Computer Science theory that was written long before we were born or started in the field. Data structures, algorithms, and optimization have not gone away; they are just dressed up in a new set of robes.

This week I have been catching up on the material from WWDC 2014 and getting my feet wet with Swift. For me, I am excited about the improvements Apple has made. 

On the flip side, I have hear/read some Apple programmers bemoan the fact they need to learn so much new stuff. I think these are the people that came into iOS programming since that is the current hotness and they needed a job. They didn't start iOS programming because the loved the platform.

I feel bad for those people that feel it is a chore to learn this. I know myself, that it is hard to chisel out the time to get current on the new APIs, language, and more but this is our job. Companies don't give you a week off to train. If you want to stay current, you figure it out.

Put me in the camp of those that love iOS. I started programming with it from day one of the SDK being available. It has been a blast and one of the most fun platforms I have programmed for. I thought a Vic-20 was awesome as a 7 year old, so I can not imagine what I would have thought of programming an iPhone at that age.

I can't get over how much I am loving Swift. The videos are such a great introduction and I can see that the hardest thing will be getting our minds wrapped around the new syntax. Being able to do so much in one line will be powerful but also take some concentration to reread. I love the power of the syntax but am reminded of my days writing a lot of Perl. I remember writing similarly super-powered single line statements that turned out were hard to debug or read a day or week later. I have higher hopes for Swift since it does not get into the crazy number of special operators that Perl had.

For me, the advances Apple has made this year are not a burden I must bear. They are a reduction in some of the boilerplate we had to write, they are a simpler way of doing things, and they are a view into the future of programming on Apple devices.

Saturday, May 17, 2014

Pushing Strings: First Week Back To Work

A local spider, pushing strings.
Well, this was my first week back to work after just over 4 months off. I took the time off to help out my kids, especially my youngest with his schooling. He was falling behind and he needed some directed attention. He has gotten to a point where he was doing great in school and we were lucky enough to find a great Nanny/Tutor to help him for the last 6 weeks of school. So, that allowed me to get back into the workforce and get back to one of my loves, programming.

This time around I decided to try something different and give contracting a try. For those not from around Redmond, here is how Microsoft and many big technology companies operate in the USA. They use contingent staffing, contractors (more correctly, vendors, the politically correct term), to help them build new products, features, or releases. This allows companies to keep staff levels lower, reduce costs from benefits, 401K, severance packages, etc in the inevitable up/down staffing cycles that occur. Wall Street likes this and so do investors.

For those that choose to contract, it can mean a higher salary if you have health benefits from another source, such as our spouse. It also means you can move from project to project and always work on something new. I am used to being a full-time employee and owning the code into the maintenance phase, so this is a first for me. I am being paid to deliver features and once the project ships my contract is over and I then find another project to work on. That's worth a try for a while I figure.

For the first week back to work, we have done a lot of planning. We have our kids in a morning program at school that includes gym and open play time. Like us they now start their day earlier. They get up at 6:30am to be to school at 7:30am. I start my day at 5:45am so I can take the bus at 6am. I jump off at the gym, near work, get a workout in, shower, change, and walk to work. Then at 4 I commute home with my wife. That's for 3 days a week, for the other 2 I drive, one day I pick up the kids early and the other my wife picks up the kids early.

The week went well, for a first week. Starting at a new place is always difficult as you have to get up to speed on the project and start delivering. As a contractor I feel some additional pressure to be productive since I can be let go at any time if my work is not up to par. So, there are less pressures in some senses but additional pressures in other areas. I did not expect that feeling.

Anyways, it was a good first week. I miss being with the kids and I miss them a ton. The last 4+ months with them have been a fun experience. Not easy (laundry, tutoring, activities) but worth it for all the extra fun times we spent together. While off I also had the house always stocked with groceries. Something ran out and I would go grab it. Now, things are missing, and it is only one week back. Now we will be back to the single trip a week since we don't have time to run to the grocery store on a whim to pick up a hand full of things.

As a family with two working parents, it is hard to stay on top of all the demands made of us each day. Work, tutoring our kids, cooking, house chores; the list goes on. Such is life.

So, though it's good to be back to working on a new project, it is bittersweet since home life is much more manageable with one of us home with the kids, laundry, cooking, temper tantrums and all. I have deep respect for those that choose to have one parent home keeping while the other works to support their family.

Oh ya and work? How is it? It's a job. It's new code and new problems to solve. But in the end they are the same old problems to solve. Push strings here. Get strings from there. Display strings.

I once joked in Computer Science class that all we do is figure out ways of manipulating strings. Concatenating, truncating, sending them, receiving them, displaying them, and not overrunning any buffers. Some days programming feels just like that day back in University. Pushing Strings.

Maybe that could be the name of an album some day or a band, The String Pushers.

Tuesday, April 29, 2014

Next Job: Contracting at Microsoft

I've just signed my contract for my next job. I will be contracting as a Software Development Engineer Test (SDET) at Microsoft.

I can not share what I am working on but it will be customer facing. Once I am allowed to share more I will. Don't you love the world of modern business? Everything is all cloak and dagger.

Start date is May 12th, 2014.

Now I just need to find a Nanny for our kids for after-school care before I get to dig into this new project.

I will miss the free time and getting to hang out a ton with my kids. That said, I am very excited to work on a new project and get SDET experience at Microsoft. Microsoft really has a great testing track for developers unlike anything I have seen or heard of at companies I have worked for. I can't wait to learn how they develop and test software.

As well, if we can swing it, my wife and I will get to car-pool together :-)