I (hope) I’m like this. Im not handy at all, and have a tenant. When a problem arises for them, I just call the appropriate person (plumber, handyman, etc..) to come fix it. It’s the same thing I do when a problem arises in my own house. Problems don’t tend to come up too often, maybe once every few months, so I don’t see why I need to pay someone to handle this stuff for me.
Seems like a no brainer - who wouldn’t want to use an awesome language like Kotlin and have it shared across iOS, Android and Frontend?
However, the actual experience is full of sharp corners. Get ready for nonexistent documentation, hacky plugins, poor debugging support, lack of proper native libraries and head spinning errors.
In general, it feels like doing carpentry using your plumber’s tools.
The problem with docs is that unlike code, documentation has no mechanism to keep it updated as things change. Even something really close to the code like code comments tend to get stale. Separate docs are hopeless - unless you are the owner of the code and the doc, and have great discipline, docs are almost guaranteed to diverge from the code.
When this happens, it’s tough to say what’s worse - a stale, and sometimes wrong document, or no document at all. So, in my career I’ve come to rely less and less on docs, and more and more on just reading the code. Docs can lie - code rarely does.
Ultimately, I file (mandatory, full time) pairing in the same category as mandatory in-office work, meant to encourage brilliance from random water cooler interactions.
In a perfect world, is a fully engaged in-office employee better than a remote one? I’d say probably yes. In the real world, is a disgruntled, commute tired employee better than a happy remote one? Unknown.
Same with paring. If your team is full of perfectly interchangeable humans drinking the same cool aid, then pairing sounds great. But real humans don’t work like that, and for every person who is boosted by pairing there may be another who is held back by it.
In the end, it’s likely best to allow employees to self select the mode of work which works best for them (location, pairing amount, computer choice) so that they are happy and productive. Any kind of top down mandatory policy on those choices will inevitably be worse than each person’s preferred choice.
The crux of it is that pairing works for some but not for others. But often, it’s forced on everyone, usually from the top down. This is done in the name of vague benefits like “correctness” and “knowledge sharing”. Have these benifits even been confirmed through unbiased scientific studies?
The problem is that in the tech biz people tend to follow blindly without thinking. There was a point there where just because Pivotal Labs had some success pairing full time, everyone followed blindly. It’s the same with leetcode style interviews,
open offices and ping pong tables - it worked for google and all of the sudden everyone is following blindly.
But personally, I wouldn’t work somewhere which paired heavily even if the benefits could be proved. I simply won’t do it because I don’t enjoy it!
Just like the choice to work remotely, the choice to not pair seems like a basic employee freedom that we should all have. Luckily, the way our industry is moving, such freedoms seem to be increasing.
The part of my brain which thinks deeply and produces elegant solutions simply shuts down when I constantly have to explain my thought process to someone else. I actually have the same problem in pair programming interviews - my brain tends to freeze up and comes up with strange, hacky workarounds at best.
Later, when I’m alone and can focus the proper answer usually comes to me. I know there are others like me who produce their best work when they can focus, alone.
If pairing works for you, then that’s great, but it needs to be consensual and optional.
The problem with pairing is that it tends to be championed and enforced by more social workers (especially managers), and forced on the less social ones, who are often not in a position to refuse.
Pairing is great for some tasks, like higher level design and whiteboarding sessions. But when it comes to implementation (coding) time I really dislike it.
I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work.
I definitely see the value in pairing for imbalanced situations (junior and senior, new engineer and tenured), but such sessions should have the goal of getting each person to operate independently, hopefully sooner than later.
Pairing just for the sake of pairing is an encroachment on many things I love about software (the ability to think about a problem deeply and quietly, the ability to work independently, the ability to check my Twitter feed as often as I damn please). I’m really glad the pairing fad seems to be dying down in general!
Daily standups can be useful when its a small group of people (3 or 4) working on the same project. In such meetings participants actually have the context to make meaningful suggestions based on other's updates "oh.. have you considered this? you should try this!"
Standups with more people working on separate projects are useless*.
My most recent standup with a group of 8 who were working on many separate projects spread across mobile, front-end and server. In this meeting, even if I did share some details about what I was doing, no-one else would have the context to help me. Also, it feels disrespectful to go into detail about something highly specific to my work while 6 other faces stare blankly as I waste their time. Ive heard stories from a friend's company of a standup with 30+ people across product, engineering and management. Could you imagine going into detail about your choice between an abstract class and interface on the call?
In such standups, the only sane action is to give a quick, high level update and mute yourself and go back to work. Standups like this should be ruthlessly dived down into several smaller meetings of people actually working together.
*Interestingly though, most people on my team love the standup for another reason - human interaction. Folks simply want to tune in and say hi to their team. In my opinion though, this isn't a good enough reason to keep unproductive standups, and the meeting would be better replaced with an optional 15 minute "coffee and chat" meeting. If folks want to tune in and chit chat, great - let them do it! But no need to waste people's time with mandatory "agile" ceremony.
Really, entering software isn't that bad. I didn't have any coding experience before college, and after my first year (which only entailed two software classes - I took a lot of humanities that year too), I had a job writing code for a research project. Thats a pretty quick path to employment - about 100 hours or less of training total*. I think any motivated person with a decent predisposition for math and logic could pick up the same skills in 6 months of effort, maybe even on nights and weekends.
I am not a super smart person either - I had an average talent and got average grades. However, the asset I do have is that I am OK with sucking and failing at something over and over again. I think this trait is more important than intellect.
Are you the kind of person that can bang their head against a problem for many days not quit? If so, you can be a software developer. Some natural intellect will help, but perseverance is likely more important. In fact, maybe being somewhat unintelligent is even better since you will be used to not succeeding at everything so easily.
*Caveat - it took me about 7 additional years to actually become good at writing code.
If you can ace a 1 hour coding interview without any preparation then more power to you! But many of us have to spend months doing practice problems to perform well in that 1 hour interview. I’ve heard many stories of people doing hundreds of practice problems to pass these kinds of interviews.
I’d much rather dedicate a weekend to solve a take home challenge using technologies I already know than dedicate many months to learn a set of algorithms I would rarely use.
I love Swift too, but dislike Xcode enough to where I wouldn't use it unless I was doing iOS. Even in a medium sized project basic functionality like syntax highlighting or clicking into functions is unreliable. You get used to it being an iOS dev, but switching into something like Intellij is a sobering wake up call where that stuff just works.
MacOS is a great example - you can buy and download software from the Apple sanctioned App Store or you can get it from other sources on their websites. The fact that I can do that on an 11 inch MacBook Air but can’t on an iPad Pro (which with a keyboard looks like almost the same device) seems pretty silly to me.
I would argue that those "hours wasting time" looking for an answer yourself before you give up and ask someone more senior aren't a waste - they are an invaluable part of becoming senior yourself.
As a senior engineer, you will often spend hours and days stuck trying to solve hard problems with noone else to ask, and having the grit, determination and creativity to do this is one of the greatest skills you can teach an engineer. Having barriers and friction in the name of this self sufficiency is totally fine and likely beneficial to the development of a junior dev.
Someone who is friendly but incompetent is fun to shoot the shit with, but they will also make a commit that breaks prod and duck out for the weekend leaving you to fix the mess. Less competence ultimately means more burden and headache for those that are more competent, and at the end of the day, I value having coworkers who I can rely on more than having coworkers who are easy to talk to.
An alternative to hacking your resume is simply leaving the short position off altogether. Your resume doesn't have to be a total transcript of your career. It should just be a highlight of most relevant experiences for your desired job.
The same goes for really old jobs too btw - having a detailed explanation of your exploits in Java Swing on page 4 of your resume is likely distracting and irrelevant. Consider making your resume a single page with older jobs grouped together like "1999 - 2008 Various software gigs for Employers1 thorough Employer5"