Why We Hire Great Developers, Not Great Mobile Developers
medium.com
medium.com
It bothers me how job ads tend to focus on various buzzwords. I'm quite sure you're better off hiring someone with good fundamentals who can learn your stack, rather than someone who is a novice but has some experience in the stack.
I started off doing financial trading code in c++ / c#. It wasn't a huge leap doing Android and iOS. Principles are the same:
- Some kind of OO. They are all pretty similar for most purposes. C++ is maybe a bit more intricate. Similarly, some kind of functional/lambda.
- Some way to access a database. Plenty of ORMs or ways to do SQL if you need that.
- Some GUI organisational principles. WinForms, WPF, Qt, Android, iOS, whatever. They tend to have things like "only draw on the main thread" and a pile of APIs for organising the screens, buttons, and so forth. But if you've done one, you're not going to need a course to do another.
- StackOverflow will tell you everything that's pure translation. Things like {} dicts for python.
- Get a brief tutorial for each new language/framework. They're all over the web, and the main point it just to highlight the features.
Do you think when Google decided to create the V8 JavaScript JIT they hired a couple of Django programmers and asked them to google 'how to write a JIT'? Or do you think they specified a certain level of experience in writing JITs on the job advert?
That really depends on what "from scratch" means. Any particular piece of code can be examined in enough detail that nobody in the whole world would understand all of them. Luckily people who understand specific pieces will produce a part for others to use. Often the only thing that hasn't been done before is one particular mashup of existing parts. Then the skill of coding is like the skill of cooking: using judgement to assemble well known parts into a new whole.
> Do you think when Google decided to create the V8 JavaScript JIT they hired a couple of Django programmers and asked them to google 'how to write a JIT'? Or do you think they specified a certain level of experience in writing JITs on the job advert?
That wasn't the point. I'm not saying that any programmer can do any programming job. But that the selection criterion (language, framework) is in general wrong. If you have a guy who did a JIT for Java, do you disqualify that guy from a JIT for Go job? I don't think so.
You might come across a ML job advert that says the person needs to know Matlab. Well, what if you're a Numpy or R ML guy? It's quite clear to me that such a person is just as well qualified.
If you're looking for a compiler guy, you want someone who understands those optimisations on a theoretical level, ie abstracted away from the concrete language. The toolset may be completely different for each language, but people with equivalent fundamental knowledge should not be separated just by what tool they happened to use.
So I'm not surprised!
The recruiter said, “I have observed that Unix hackers scowl or become annoyed when I ask them how many years of experience they have in a new programming language. Why is this so?”
Master Foo stood, and began to pace across the office floor. The recruiter was puzzled, and asked “What are you doing?”
“I am learning to walk,” replied Master Foo.
“I saw you walk through that door” the recruiter exclaimed, “and you are not stumbling over your own feet. Obviously you already know how to walk.”
“Yes, but this floor is new to me.” replied Master Foo.
Upon hearing this, the recruiter was enlightened.
--Raymond, Eric S., ed., "Master Foo and the Recruiter", Rootless Root, http://catb.org/esr/writings/unix-koans/recruiter.html
Though I note that in real life the recruiter would never be enlightened. He is beholden to the HR departments, and the HR departments have settled on a system which works for their purposes.
1) Learning the intricacies of a language takes some time before you're truly proficient in it.
2) Different languages demand a different approach to problems, a different style of forming the solution. A programmer with 10 years of experience in Ruby and 0 years of C is less desirable for a C programming position than a programmer with 5 years of experience in C. Though the Ruby programmer will be quick to pick up Python, he/she never had to deal with manual memory management, pointer arithmetic, and all the pitfalls that come with those.
Am I the only one who finds that weird? During my 5 years of college education in "informatics" I never had a 'programming for..." course. We were taught how to tackle problems, algorithmics, patterns and practices, formal languages, ai, distributed mechanisms and so on. We had to get that hard concrete experience on our own. IMHO having courses like "programming for Android" or "Web/JS programming" is a great way to mass produce monkey programmers.
Definitely, I took a RoR elective and I wish there had been a Lisp/FP elective I could have taken. I'm pretty sure I only had one class where first class functions were even mentioned.
The grads from good (not necessarily great) schools tend to have solid fundamentals, and even without lots of "buzzword" coursework, they come out better. The grads from mediocre schools often have more buzzwords on their resume, but often lack solid fundamentals.
Of course, that isn't written in stone. We have several great new hires from schools that are typical regional universities.
And you think it's their course material...
Programming is a barrage of 'problems', you don't need a course on 'problems' if you actually just programmed.
So perhaps they do need to change like this.
There are relevant different design decisions to make that go much further than just a touch screen vs a mouse. You don't want to drain your users' battery or drain their wallet by going over their data limit, you make different decisions about what part of the workload to keep on the client or move to the server.
My impression is also, that it has changed a lot on Android.
Personally, I also think that, in the beginning, many parts of iOS-development felt more modern than OSX, and that this was the platform where things were maturing faster.
I would say, that mobile development is like development on most other platforms these days. You have an increasingly larger choice of languages, and the Mobile CPUs are certainly powerful enough that you can build very complex apps, where elegant code is an advantage.
The challenge is to keep things simple from a user perspective.
It really is (still) a wonderful domain to develop in, and I doubt there is more debugging or trial-and-error than any other platform!
I worked for a company that embedded Linux on a custom device about 15 years ago. That was a horrible debugging, trial-and-error experience. The language was C. Chosen as a compromise because of the hardware specs, but not an obvious choice for the applications we built. Certainly not today. Most of the development team was frustrated with the development process, and I actually left the company before the product was put in production.
So I think, I understand your line of thought, but I don't recognize it in today's mobile development.
Personally, my typical web app is not CRUD, it's merely an R. And I don't write those daily. Much more often I write network or system daemons.
That's why REST and JSON are great. Very simple and perfect for many web use cases.
Indeed. To avoid the CRUD groundhog day, I'd stay away from both web and mobile.
Games, Desktop apps, Industrial, embedded, ...
Personally I do desktop applications and love it.
I simply don't believe that a domain (understood broadly, ie. desktop/mobile/web) in and of itself dictates whether projects are original and interesting.
Not until you work on something really specialized, like AI etc.
They are usually only interesting if they are desktop apps because they have to, like image editors, games, CAD.
My test for interesting work is the fraction of lines of code that relates to processing data and not just input/presentation/persistence/validation.
Other people have different definitions for "exciting". Don't knock someone else's idea of it just because you don't agree with it.
What I generally do is write web apps, and much of my enjoyment comes from figuring out how to creatively use other people's libraries and to write very DRY code.
The libraries I use abstract browser fragmentation away from my presentation layer, so I don't have to do endless run-debug-fix loops on the front end.
At this point, the code I write for each new project is 90%+ unique to the project and very thin, so I get to do the fun part of releasing and iterating it.
On the other hand, due to limited resources libraries tend to be as they should, light-weight and modular. None of these mammoth frameworks enterprise devs have to cope with. No AbstractSingletonProxyFactoryBean.
Though, I'm more motivated by what I could theoretically do [faster|more comprehensively|repeatably] with code than I am with it in of in itself, and occasionally I like acting on such. Having x number of beamformers targeting different brain regions that I can customize quickly without interfering with timing of processing a signal or buying/making more analog hardware nor completely wasting cpus/memory to my own tolerance is cool, caring whether I use structs vs this or that some class inheritance scheme vs this or that implementation of shared pointers vs tabs or spaces… I couldn't care less about in of in itself and find myself annoyed when I have to deal with such talk.
As someone that occasional does some hobby Android and WP coding, when time allows, it is quite interesting to see this type of attitude.
Here in Germany many IT companies seem to disregard skills if they aren't listed as part of the previous job. Regards of what one would be able to show at the interview, if HR didn't filter out the CV.
So no chance of switching tech stacks unless one is able to land in a greenfield project that is taking off, inside the same company, before doing the jump.
Once an HR drone has explicitly told me that my side projects had zero value for the application, even though they matched what was being searched for.
Hopefully this is a dying practice.
On the other hand, if you know PHP, JavaScript or Java, you're pretty safe.
I've taught C# and the .Net framework to several teams over the last two years. The good developers pick it up without much problem. But, we usually start with several sprints of co-located group programming (for complete teams learning the stack).
It takes a bit of working with the PM to determine what is a good task that isn't super time sensitive but it's typically a solvable problem.
It seems like everybody sharing their interview experiences says they all use the same Google-wannabe standard. Ie whiteboarding, implementing an advanced data structure from memory, and rapidly solving CompSci homework questions.
I'm no CompSci grad but I have pretty a pretty experience in many languages/stacks. I have confidence that I could design and implement a reasonably complex distributed architecture if requirements called for one. Yet I'd look like a complete asshole if asked to whiteboard a R/B tree from memory.
Why are you asking these meaningless questions, that don't give a chance to demonstrate any relevant knowledge?
Everyone does that, duh.
HR has no ability to objectively judge technical talent, so they follow the latest 'flavor of the month' interviewing strategy.
The suits are heavily influenced by sources like Business Insider that repeatedly parrot advice about avoiding 'false positives at all cost.'
Meanwhile the tech specialists who should step in and call BS, won't because they're to arrogant to admit their own hindsight bias. Ala judging new candidates based on their current level of ability and specialized knowledge rather than the level they were at when they were initially hired.
It seems like the industry is dead set on forcing the perception that software development is hard science -- as in -- everything can and should be described in terms of fundamental data structures and algorithms. When the reality is, software development is 95% art and about 5% hard science.
The vast majority of clever algorithms and data structures can be implemented in less than 100 lines of code each. What accounts for the other millions of lines of code in a system such as the Linux kernel?
The world will never know...
We've used good developers on iOS projects, and while they would do ok with actual logic, they didn't do well when it came to Core Data or UIKit. It's not an education problem, but an interest issues. Most of them used Androids, the ones with iOS devices really didn't care much about UI.
But I kinda agree with this in other aspects.
I do agree with the idea of hiring decent engineers and just training them, my only concern would be that without having had the mobile experience they might not know that they don't like it - it can be quite painful getting code to work nicely on a large collection of different hardware.
It's a bit like saying "don't they know human flight existed before the Wright Bros." or "don't they know cars predate the Model T?"
Of course, but the iPhone (and subsequently Android) presented a gigantic turning point in mobile development, to such a degree that mobile development can largely be categorized into "pre-iPhone" and "post-iPhone".
Pre-iPhone mobile development was a vanishing small industry compared to today and used technologies that are largely completely not around today (see: J2ME, Symbian, Windows CE).
So yeah, maybe they could've said "mobile development in the modern context centered around multitouch-centric interfaces using soft keyboards has only been around 8 years", but that's kind of a mouthful, and unless we're trying to write an accurate history of mobile software, not particularly relevant to anything.
The big shift is that touch became the only game in town (along with all the associated dev wrinkles). Also the demise of all content aggregators meant we could just upload our apps to a store and keep 70% (prior to this we got ~20% i.e. operator took 60-70%, aggregator took 30% and we got 50/50 on that).
Just showing my age really :^)