In this comprehensive list of matureness in engineers, John Allspaw elaborates on many of the non-technical skills that constitute seniority.
The things that will actually allow you to hire great engineers are things that are very hard to quantify, as listed in this article:
Permission and encouragement to do my job right
Working with and for smart people
Making a good career investment
An excellent talk by Tanya Reilly about the career impacts of technical and glue (non-technical) work especially for underrepresented groups: “Being promoted is diversity work.”
I’m not a data scientist but I’ve been trained for it (as part of my computer science degree) and I’ve worked in a bunch of related fields. I wholly endorse this take by Vicki Boykis on the state of data science and what you need to be successful at it.
1. Learn SQL
2. Learn a programming language extremely well and learn programming concepts
I dropped by the UIKonf unconference yesterday and gave a quick code/architecture talk. Normally I do mostly design/strategy type talks which are a lot more handwavy, so this felt a bit out of my water.
Besides actual code I threw in some talk about impostor syndrome, the value of cleaning and maintenance, gradualism as defined by parkour and Christopher Alexander’s “A Pattern Language”.
I think there is a lot of value in getting more different perspectives into the standard programming talk. I have seen enough engineering talks by now and many of them suffer from a lack of diversity.
I saw a starter task fly by in the Swift Weekly Brief and jumped on it. Now it turns out that the Swift project has a util directory full of various Python scripts that perform various tasks including cloning and building the project.
One of those python scripts needed to print out a message if somebody calls it without the –clone parameter. If you don’t do that, it doesn’t clone all the repositories that you need to be able to build the project. I did some path fiddling and testing against a sample of directories that should be present and there is PR #12856 that got merged into the project (and got mentioned in the next Brief).
I had to run the thing by the people who have testing/merging privileges a couple of times mostly because of how stringent Python linting is these days. Writing code that adheres to PEP8 is no joke but I’m glad that people have set such a high standard for themselves and the community. I got commit access to another project and figured out how to run the linter there until it was happy with the code on my machine.
There is also lots to do even just in the python part of the Swift codebase without me even having to dive into C++. I also have 15+ years of python experience to draw from vs. two months or so of C++. I’ve been looking around for some other python starter tasks to contribute some more stuff but still have to find the time to do them. Whether I’ll get around to ever contribute to the core project is still open, but knowing how to build and run Swift is useful if I want to try out some of the interesting new proposals.
I’m very glad too that the Swift project itself has chosen for python as its scripting language. Too many iOS tools to my taste are written in ruby a language I have zero inclination to learn. I taught myself a bit to be able to get a plugin into fastlane, but that was more than enough. But it looks like we may be able to get rid of ruby in the future since more and more functionality of fastlane is being rolled into Xcode and cocoapods is being superseded by the Swift Package Manager. SPM especially is a project where there is still a lot of rather accessible work to be done which will yield huge improvements in the quality of life of lots of developers.