The top of the heap reaches out

If you made a list of the most prestigious software companies, the best, most desirable places to be. At this time in July 2021 the top of the software heap might look like

Google
Facebook
Microsoft
Apple
Amazon
Netflix

and right up there, not far behind I might include

Zoom
Uber
Twitter

now your list might be a bit different. maybe add or remove a couple here and there. but in general, these are considered the top, the biggest and most successful companies, the most sought after jobs. some use FAANG which is basically the same list.

what's interesting is that in the last few months two of these companies have reached out to me unsolicited from LinkedIn. I've been contacted by Amazon and Facebook. asking me if I might be interested in applying for something. I told them polite thanks, I'm not looking to make a change at this time.

I've been on LinkedIn for a long time but this had never happened before. So it's a bit unusual for me to be hearing from them. I haven't really made any meaningful changes to my LinkedIn profile that might be drawing extra interest from the search queries the elite companies presumably use to assemble lists of people to reach out to. But somehow I've now appeared on these queries twice in the last few months.

I'd think historically they have had plenty of high quality applicants to choose from. I'm basically a regular software developer in Nova Scotia with north of 25 years experience. It's a bit flattering to hear from them. Still I understand how rigorous their recruiting process is. I don't have any more illusions now than in the past about being able to successfully navigate that notorious process. It's a long way from sending an unsolicited email on LinkedIn to extending an actual job offer.

I got thinking about why they now seem to be reaching out further to find candidates. I suspect part of it is just how successful these companies have been, and how much they have grown. They may have outgrown the ability of traditional recruiting sources such as Stanford, CMU, MIT, Concordia, Harvard, other companies in Silicon Valley, to generate employees. So they have to be more creative to search further afield to find quality new employees to hire. Then there's Price's Law. It takes 1 million programmers to generate 1,000 exceptionals, the people Google wants. It takes 4 million developers to generate 2,000 exceptionals.

The 1 in 1,000 exceptionalism. These people are great of course and highly sought after, but are very rare. There could only be a few thousand in all of North America. Many are already onboard at Google and Facebook anyway. Of the rest, many have great situations in academia or the companies where they are at. They can't be lured to Silicon Valley or Seattle. I'm guessing the target for elite tech hiring is more around the Pareto principle. Under Pareto, 20% of developers generate 80% of the software progress. If we accept my speculation that the 20% Pareto group is a fractal, it's also Pareto distributed. Then 4% of developers create 64% of value in software. It's these 4%, the 1 in 25, who big tech is reaching out further to identify and recruit.

One factor which may be influencing big tech to reach further out is the increase in work from home. If there is some guy in Cape Breton who is outstanding, and would do fine in California. He is happy living in Cape Breton and not interested in moving. With work from home, big tech might be able to still recruit him, which would not have been possible in the past.

It's a big challenge for the elite firms. How to continue to grow and increase the head count, while maintaining the extremely high recruiting and hiring standards that have made them so successful. Reaching out further, to less familiar candidate pools, may increase this challenge further. Though there are outstanding people "out there" to be found. I've had the pleasure to work with a few over the years.

25 years in software development

A few months ago, in 2020, I realized something. I started my first job in software in 1995. I've now been a computer programmer for 25 years.

My first job was with PRIOR Data Sciences in January 1995. I was a co-op student from the Technical University of Nova Scotia (TUNS) on a four-month term with PRIOR in the Halifax office. The pay was based on annualized $25,000 a year. it was the highest pay I'd received anywhere. yay good start. Working in software has always paid well with good benefits.

The project, PLAN CSCI at the time, was part of the Iris radio program for the Canadian Army. PRIOR had this small piece of a big program, which was a big multimillion contract to PRIOR, and created a job for me. We were actually a sub-subcontractor, working for EDS in Hook, England, who were working for CDC in Calgary.

It was a good work term. I worked on Oracle Forms and some Ada. I wrote the original forms manager module which continued into the final completed system. I learned a lot.

I guess PRIOR was happy enough with my work. They invited me back for two more work terms, then when I finished at TUNS I joined as full time in January 1997. PRIOR was a fine company, a good place to work, with talented individuals throughout. In 2000, xwave bought PRIOR for $15 million as part of an acquisition spree.

I joined xwave with the acquisition. They were okay, benefits weren't as good but they treated me well and I can't say anything bad. xwave had the bad luck to hit the tech crash of the early 2000s. It was a different feel with xwave. For myself I made my first job change, joining Core Networks in July 2001. The pay was 8% higher.

business cards from over the years. developers were last issued business cards about 15 years ago

Back then, working in software development was in three broad areas
product based companies
consulting and systems integration
corporate and government IT departments

I've worked in all of these environments at different times over the years. My IT department time with the Department of Fisheries and Oceans (DFO) around Y2K for about two years was as a contractor from PRIOR/xwave. Showing that there is some overlap between them.

This is still pretty much the same today a generation later, the three areas where developers work. Some of the details are a bit different. Products then was shrink wrapped consumer, and enterprise software discs for corporate servers. Today it is websites, web-based applications, and app store apps.

Consulting has seen the rise of outsourcing and offshoring.

In enterprise IT, more servers and corporate applications have moved to the cloud and AWS.

I started as a software developer in 1995. In 2020 I am still a computer programmer. That's not entirely unusual. it's a good job, the pay and benefits are good. Indoor cubicle work (from home) with free coffee. Like everyone in tech, a good number of evenings and weekends, with a few death marches and all-nighters over the years. 

Some who started as programmers have moved on to other positions. The main areas people branch out to from development are management and architecture. as for everyone, there were opportunities where I could have moved things in those directions. meh I've always been happy enough to be a developer.

I think about it like an electrician. If someone is an electrician for 25 years that's considered good, an accomplishment, a winning career. Nobody would question why an electrician didn't seek to become some kind of manager or start his own company or whatever. He became an electrician to work as an electrician. He was good enough at it to stay employed and had a long prosperous run doing it. A success.

When I joined PRIOR full time PLAN CSCI had expanded into the Communications Management System (CMS) Segment, which included PLAN. My contribution was the Offline Storage Media (OLSM) Computer Software Unit (CSU). OLSM was a good piece, well received by the Army in testing I was told. I'm pleased to have written it and be associated with it. OLSM was written in the Ada programming language, now known as Ada 83. I was on the Ada team for CMS. That was a very strong team, certainly among the best teams I've been on over the years.

Ada is a good programming language. It can be enjoyable to work with on a good software system. At the time I thought I wouldn't mind doing Ada maintenance on a large, well-designed system for a number of years as the rest of my career. That statement remains true today.

At this point it's likely I'm closer to the end of my career than to the beginning. 25 years ago I was close to the start with years ahead as it has turned out. There's no guarantee of course I have 25 years left to live, and retirement is a real thing for some people. So who knows? Unexpected events, major upheavals for better or for worse, periods of prosperity and struggle, can and do happen. The world of professional software development has changed in the last quarter century, and I expect change to just continue. For myself I'm definitely in the "danger zone" of the middle-aged tech worker. As far back as the 1980s the unemployed 40 and 50 something technical worker was a thing, an issue in tech. I used to see articles about it in high school. We don't hear about that as much today, but I'm not sure I'd want to be out of work and seeking to get back into software.

I've worked for 7 different companies. So about 3.5 years average. That's not bad in software. Some of the changes such as PRIOR to xwave were due to my company being acquired. I switched jobs on my own three times. Luckily I was only laid off and out of work once in all these years so far. In 2014 as RIM was going from 19,000 to 2,000 employees I got severenced when the BlackBerry ID (BBID) server team in Halifax was laid off. A couple of months after RIM I caught on with CGI.

lapel pins from along the way. TUNS, PRIOR, and Core Networks no longer exist

Final thoughts. I've been on a number of teams with a number of companies over the years. There have been many theories and methodologies including: personal offices with doors that close, pair programming two people at one keyboard, shoulder to shoulder and across from each other at long desks, work from home, Booch notation, Unified Modelling Language (UML), stick figure men, user stories, scenarios, design patterns, Microsoft Word design documents, MS Project, Jira, waterfall, agile, scrum, SAFe, kanban, Toyota, Spotify, probably other stuff and fads I've forgotten.

What makes a successful software team? From the above, it has been thought about and many ideas have been tried. In my early years as a developer I came up with a theory. I've stuck with it ever since. My theory is there are two factors that define a successful software team

• outstanding individual talent. exceptionals and solid individual contributors
• stability and continuity

With those two things the team will be successful whatever current design methodology or way to organize people and work is used. Without these two things, especially talented personnel, no amount of software design or organizational fads will overcome it; the team will struggle.

That's it. twenty-five years in the books. it was a good choice for me getting into this business. hopefully I have at least a few good years left.

Is Code the Future of Test

Where I work there is increasing focus on test automation. Recent hiring around the quality assurance area has focused on those who can create and maintain automated tests.

Test automation is about source code. So at least some programming skill and experience is now basically a requirement to be hired into QA. Of course there is still a requirement to be able to do more classic manual testing. That is, going to the website, desktop, or mobile app, executing various flows in person, observing and verifying the result is correct and the user experience is smooth. The way forward seems to be dual-hat in QA. Comfortable both in manual testing and test automation.

This tends to blur a distinction between manual and automated testing. It's all testing. The trend in my observation seems toward eliminate the separate test automation teams, the 3 teams doctrine (dev team, manual test team, test automation team).

It also tends to blur a distinction between developer and tester. Going forward it may become that QA/test automation is generally the entry level position out of tech school. From there, the individual will have the opportunity to demonstrate an ability to write clean, maintainable code that works as part of test automation. That person could if interested be offered an opportunity to switch from QA to development.

So I'd see a scenario something like this where dual-hat QA is capable both in manual testing and test automation. While manually testing a screen on the website, a tester notices a problem. The tester files a bug report in the usual way, reporting steps to reproduce, expected result, actual result, screen shots, logs, etc. While the bug goes into the development team, the tester then creates an automated test to demonstrate the defect on the website. The automated test is reviewed and checked into the repo. A couple days later the development team marks the bug as fixed and ready to verify.

The tester goes back to the screen on the website with the latest build. The defect is observed to now be fixed. The automated test case runs automatically. The automated test switches from red to green, confirming that the issue is now fixed. The defect is closed. The automated test remains in the repo and runs in the overnight regression test run to help ensure the defect does not accidentally reappear in the website.

What of the classic manual tester?
I think the traditional non-coding manual testers will be around for some time. There's plenty of work in that area. They are not yet an endangered species. Not every company has fully embraced dual-hat QA. Anyone who has a job manual testing is probably pretty safe.

Perhaps it will start to be felt in mobility if you lose your job or seek to switch jobs. For example where I work it seems all new QA hiring now requires coding and test automation ability. So by that definition any manual testers here might have a harder time getting hired by today's standards, even though they are good at their jobs and make important contributions to successful product releases. So I suspect QA hiring across tech will increasingly require the ability to fire up Eclipse, Visual Studio, whatever IDE, understand code, and write code.

To the existing manual tester there are some paths forward. Be really good at manual testing. Consider reinvent as a business analyst, product manager, project manager, or into management. Also if possible fire up the tools and learn/relearn to code and embrace test automation.

What is the future of Development?
I think that will also evolve. It's worth its own post. I should think about it some more and may come up with something.

2 Years of C# and .net

Hey, it's been a while. This site is still active. I just don't seem to have much to write about. I still work in software. January 2017 marked 20 years doing this work. It's a pretty good career all in all. The pay and benefits are good.

Back in late 2015 I switched jobs and joined my current employer. It's pretty good here, and it has been a positive change. After RIM ended abruptly in 2014, my previous employer gave me a job when I was out of work in the summer of 2014. I appreciate them for that. It was what I expected and I don't have anything bad to say.

When I joined my current job the initial plan was around factoring out a piece of a large monolithic Java application so that it could be called from a .net client. As things turned out I pretty quickly ended up working on the .net side. There has been a smattering of Java here and there since then but primarily I've been working in .net and C# for a little over two years now.

I'd never done anything in C#, .net, or Visual Studio before. I'd heard some good things about .net but it was new to me. So at this point I have about 4,000 hours in on the Microsoft stack. It does make a difference being at it this long. Still learning and still not quite mastered. 6,000 hours to go I suppose. Though working with it for several thousand hours does make a big difference in proficiency and speed.

The .net stack including ReSharper is really quite good. Really well thought through, powerful, and easy to build applications with. Coming over from years in Java, the whole developer experience from C# to Visual Studio, to the .net libraries, it has been a very positive experience. C# is an excellent programming language. Powerful and well thought through. And LINQ is just incredible, and built right into the language, the intellisense.

Java and Eclipse is a great developer experience too I will add. I'm not going to declare a winner, both approaches are very well done and developer friendly.

I've done a lot of Web stuff with the .net implementation of MVC. And the Microsoft take on MVC with Razor is an excellent implementation. Everything is just there and just works the way you would expect. Microsoft really has worked hard on this and done a great job. I'd never really understood MVC before and now I've seen it done right it is a great approach to the Web. It was a great decision to have MVC right out of the box as a first class Microsoft module, it was very wise differentiator for Microsoft to own the MVC, instead of leaving it to the whims of third party vendors or open source for better or for worse.

Also I've worked more with the SQL Server database the last two years. Mostly Oracle over the years before coming where I am now. I've gained a lot of respect for MSSQL and SQL Server Management Studio. I didn't know much about MSSQL, but I will say it's a great database and does a number of things very well.

The 5 whys and escaped software defects

At training recently there was some discussion about using the Toyota "5 whys" line to get closer to the root cause of problems. Though Toyota wasn't mentioned. There was a bit of context around software defects and trying to trace back "further", so that in addition to fixing the immediate problem, find and fix more systemic issues that cause some categories of defects to recur.

it got me thinking a bit. In the past such as at SupportSoft there would be discussion and even tracking and measurement of "escapes", that is defects that made it into the field and were first reported by end users. So the error was missed by all of developer testing, code review, test automation, and the QA test team. I'd always found it strange that all of the focus and serious face talk about escapes was on the test team. The escaped defects were always blamed on QA for "missing" them in their test plans.

We never did further analysis to trace defects back further into the development team or individual programmer who checked in code that didn't work. I wondered why was the "blame" always on QA for escapes. They didn't write the code that didn't work. Oh well. I'd say the "pinning" of escapes on QA is from a mentality where quality is something that a test team either adds or fails to add as the final step in a software development process.

With 5 whys, things change in a more positive way. QA becomes a link in the chain, however if there are escapes then the entire team is accountable including original developers who checked in code that ultimately errored in the field. There was a chain of events that led to a runtime error in the field and QA is one link in the chain.

It's a new mentality, different than other places I've worked. Before it was understood and accepted that defects are a natural, unavoidable byproduct of advancing a software program. Development delivers code with defects, QA identifies the most important defects, development fixes them, dev/QA iterations occur, and everything moves forward and code ships to production.

With 5 whys we implicitly reject this silo model that code thrown over the wall out of development is expected to also include defects for testers to identify. With 5 whys and root cause the expectation becomes far higher initial quality out of development, with few or no defects, and far fewer iterations where software is "sent back" from QA to development for rework. Also there's more of a team approach to responsibility for quality of code delivered into production. Defects are owned by the entire team, they aren't something that testers either find or fail to find as the final step. Quality becomes more pervasive and end to end.

Five year plans

I've just done a training session. It was pretty good. The instructor made one point that was interesting. He felt that making a personal where will you be in 5 years plan was pretty pointless.

Thinking about it he's basically right. There's no way to project what will happen that far out and things we have no control over.

I thought back 5 years to September 2011. At that time I was with an UCCDI team as part of the blackberry platform group. The platform was about 1200 people total. since then this is stuff that happened that would have blown any 5 year plan out of the water

One day in fall 2011 we came to work and platform had been dissolved and UCCDI was no more.

Sorry after UCCDI was assigned to some existing team called Devops. It was quite a different culture and I was a misfit on that team despite working extremely long hours during the BB10 death march.

Luckily I escaped Devops and was able to switch to BlackBerry ID server at the end of 2012. That was a pretty good run with bbid server.

By the end of 2013 the Halifax bbid server team was attritioned down from 5 people to 2 and the team was dissolved. Me and the other Halifax guy were assiged as lone remote members to Ottawa sprint teams. In June 2014 there was another reorg and I was laid off from rim. That sure wasn't in the 2011 plan.

Luckily, shortly after rim ended I caught on at CGI and had a successful year and a half run there. Nearshore offshoring for a global European investment bank. It was good to be a senior again and have some status and actually write features.

Then late 2015 I caught on at ResMed where I am finishing up my first year. I also switched from Java to .net. I hope this can continue long enough to review what actually happened in the next 4 years here. It's good here.

Still to my point. from September 2011 to now a number of major things happened any of which would have blown out any 5 year plan. The same is true of a 2006 plan at SupportSoft when the future was to leave for RIM. A 2001 5 year plan at PRIOR could not have accounted for the xwave takeover, going to Core, the SupportSoft takeover of Core Networks.


So I agree in tech 5 years is too long and too much will happen. You just have to be able to adjust and deal with and advance yourself in whatever will unfold.