Depth vs Breadth of study and career variety

I read this thought provoking blog today


Career Monogamy: The Awkward Tech Sin of Longevity


It's by Brian Nemhauser who has worked for Adobe for a Long Time! He says:
Other fields, like academia, have learned the value of encouraging depth of study over a lifetime. The tech sector is based on the belief that tomorrow will be better than today. Anything that even resembles stagnation is antithetical to the core value system that fuels our industry.
Longevity, however, need not equal stagnation. It can mean wisdom, passion, dedication, and sustained peak performance. 
Brian talks about changing jobs lots of times, but still working for Adobe.
I've certainly changed jobs lots of times to, but in Australia this entailed having to change companies as well as there are very few large tech startups that you just stay in for your whole life. Particularly in Canberra :-( I think I've worked for about 7 organisations, but probably more "jobs" or roles than that. 10+. I also observe that each role often involved multiple skills (primary, secondary?) and than each new role/job often meant changing from the primary to secondary skills  (which became primary), and then learning new secondary skills etc.  E.g.
Machine Learning + UNIX
At UNSW I was doing R&D in machine learning, but also using UNIX and teaching distributed systems.
UNIX + Software Engineering
My next job was UNIX systems programming and training, using some of the AI skills but learning new skills in UNIX and software engineering and process improvement.

Software Engineering + Leadership
My next job was with the CSIRO SEI and used my software engineering skills and training and a few specialised technical skills but required learning new software engineering process methods and tools, management skills and training (across distributed projects etc). 
Leadership + Java/Software Architecture
My next "role" (still with CSIRO) was as a software project manager and architect, trialing some of the tools and methods in a single project and project leadership. Also involved more stakeholder skills and learning a new programming language and OO method (Java, UML, GUI prototyping and tools etc). 
Java/Software Architecture/Leadership + Middleware/Performance Engineering/Distributed Systems
Guess what? My next role (also in CSIRO, but in the Maths and Stats division) was in the middleware evaluation project pickup on my Java and architecture skills. What did I know about Java middleware? nothing much but I had to learn it fast and became an internationally recognised J2EE middleware performance and benchmarking expert within a few years, and represented CSIRO as the primary SPEC Java representative.
Software Architecture/Distributed Systems + Grid Computing
My next role in CSIRO was in yet another project, the Grid astronomy cluster project. This built on my middleware experience and distributed systems knowledge applied to Grid web services and middleware.
Grid Computing/Leadership/Distributed Systems/Performance Engineering + Distributed Systems
I was then "poached' by UCL to managed a distributed Grid middleware evaluation project in the UK for a year. This project required high level s/e engineering, architecture and management skills, and leveraged my Java, middleware, and Grid/middleware experience. I had leave from CSIRO for year in the category "of benefit to CSIRO" with the expectation that new skills I developed would be applicable when I came back to CSIRO (sort of).
The UCL Computer Science department was a very high level learning experience. Professor Wolfgang Emmerich (and other leaders in the department, PhD students and students, and other project members and stakeholders in the UK eScience community) were great to work with and provided one of the most stimulating working and learning environments I had experienced for several years. I learnt about and practiced distributed systems theory and practice, distributed project management and leadership, invented several new enhancements to Grid (cloud related features), attended interesting conferences and wrote and presented several papers and presentations. 
Distributed Systems + Stream/Event Processing/Data Analytics
Back in Australia and the CSIRO ICT I had several new roles including integration architect, and sensor (stream and event processing) networks standards and technology evaluation project technical leader (a type of distributed system so related to previous experience).  What did I learn new? IoT (ESBs, streaming data, RFID etc). 
Leadership/Software Architecture/Distributed Systems/Performance Engineering + Data Analytics/Modelling and Simulation/Cloud
I was then "poached" by NICTA to work as a senior research scientist in the new eGovernment project with the Software and System research group.  This focused on SOA and systems of systems/enterprise software R&D and I invented and commercialised a technology for predictive analytics of SOA systems using performance modelling and simulation from APM data streams.  In a sense this research, development and consultation for clients built on everything I knew including machine learning, data analytics, stream and event processing, and distributed systems, SOA, software engineering, performance engineering, benchmarking, middleware, java, and leaderships including product development, client management, and programming etc.

Leadership/Data Analytics + Application Performance Management (APM)/Technology Innovation
Finally in the CTO/startup role I was doing a bit of everything, but mostly had to expand my "soft" skills around product, client, company and IP leadership and innovation, and revisited and learned new skills around machine learning, cloud and APM products.

It required research of all these areas and increasing my skills in them,  development of solutions across all these areas, and then application to many of these areas (many clients had technology stacks and problems across them, and increasingly in the new areas such as cloud, data analytics, new open source products including streaming data and NoSQL, mobile, HTML 5, APM products, and Agile methods including DevOps, CI/CD, Cassandra, Apache Hive, Spark, SPLUNK, etc). We also used many of these approaches in our our product. 
What did I learn new? Modelling and simulation. SPLUNK. APM, Apache and DA/ML (mostly familiar from CSIRO, Grid and UNSW ML days). Cloud.  Data and Model driven approaches. Performance Engineering R&D and reconnecting to the international academic and professional performance engineering communities (E.g. ICPE, SPEC RG). Technology Innovation. New ideas (e.g. performance modelling of Data Analytics Platforms).
So what do I know how? No much about most things? Everything about a few thing? Yes and no. Here's an attempt to graph what I've known over time (measured purely by publications  and/or deep hands on use in main topic areas). 


What will I end up doing next? Not sure, but probably something that's in the Technology Innovation/Startup/CTO, s/w architecture and engineering, APM, Java, cloud, distributed systems, data analytics, IoT, streaming data, micro services, serverless, leadership, consulting, R&D space. It's pretty big. And hopefully learn/and use something new! My guess is AWS, Lambda, Kinesis, a new language (Julia, Scala, Javascript, Gremlin/Pixy? Graph Databases, etc). 

Comments

Post a Comment

Popular posts from this blog

Chapter 11: AWS Directory Service, Cloud Directory

Image
"Name or Number please?" So the 1st telephones systems were point to point, and then hub and spoke. You rang the local exchange, asked to talk to Auntie Jill and the "operator" (think the Matrix) would ring Auntie Jill's phone and connect you (literally with a patch cord) once Auntie Jill had answered. If you wanted to talk to someone not on the local network the operator would call another operator (how did they know which one?) and ask to them to connect and you would eventually get patched through. This was even more fun if you wanted to ring someone overseas, as you would hear the patchwork of operators, some speaking foreign languages (what fun), the the sounds getting fainter and weirder (lots of clicks, "undersea" sound effects like talking down a tube, echos, etc) until finally you heard Auntie Jill's voice saying "hello?" and you could talk to them (which was expensive, and the operators would sometimes break in and say...
Read more

AWS Solution Architecture Certification Postscript

Image
So I sat the exam today and past ok yippee. Guess there's no need to continue blogging about AWS certification stuff!? The AWS Certified Solutions Architect – Associate exam is intended for individuals with experience designing distributed applications and systems on the AWS platform. Some general observations. The real exam is somewhat harder than the practice tests and practice exam (about 10% harder?) NONE of the practice test questions appear in the real exam. The focus is only what I would call the legacy IaaS Amazon services. Almost no questions on managed services, Machine Learning, Data Analytics, Lambda, etc. Lots of questions on what I would call systems and networks admin stuff.  I spent a few months trying to learn this stuff but actually I don't think it helped, I'm not sure I got any of these questions right. E.g. the sort of qns were if you have this sort of set up (VPCs, subnets, ACLs, groups, EC2, etc) and this doesn...
Read more

Chapter 2: Amazon Simple Storage Service (S3) and Amazon Glacier Storage (for storing your beer?)

Image
Chapter 2: Amazon Simple Storage Service (Amazon S3) and Amazon Glacier Storage The Amazon Glacier Storage Service is designed for cheap long term archival storage, so you want things to stay put in it for a long time. It is a slightly odd choice of name these days given that global warming is a significant threat to Glaciers (Glaciers are "shrinking" and large dangerous chunks are falling off them as in the above image of the warning signs at a famous New Zealand Glacier (Franz Josef Glacier).  Maybe the Amazon "Glaciers" will be the only ones still around in a few 100 years. I initially found it "odd" that the AWS Solutions Architect Certification book introduced storage services before compute services.  However, in hindsight this sort of makes sense as S3 is one of the original services, is core to other services, and introduces many of the AWS concepts, and is a "managed" service so it simpler and more typical in some respects. ...
Read more