955 karma · joined October 1, 2013
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.
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.
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 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.
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.
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!
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.
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.
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.
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.
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"
Here is your world of underground freeway biking btw
I have made an effort though by reading a few books in Russian, including Crime and Punishment.
The author saying “I have so much to say, but not the words to say it” is the heartbreaking reality of my conversations with my parents. Luckily, my ability to understand is still sharp, so I get them talking and hear stories about their lives.
Sound suspiciously like a "paragraph about why we should hire you"
I can see this interviewer writing feedback like "Well, this candidate didn't come up with a perfect implementation of Dijkstra's shortest path algorithm, but its OK, they were pretty close. Oh wait, they are a senior engineer? Nevermind... they should have really mastered these algorithms while building CRUD APIs all these years."
Now imagine that your table view has 20 cells, and each cell is managed by a team of 5 people and needs 1,000 lines of code to fulfill its business logic. How would this approach hold up? Would you have all 100 people working on the same `cellForRowAtIndexPath` method, piping every event for those 20,000 lines of code through there?
When people talk about scale on iOS, they are talking about potentially 100s of people working on the same screen. With something like React, this is trivial by having each team work independently on its own components. With iOS, its much harder out of the box.
One particular challenge is lack of modular components and component nesting. For example, if you have a list view, it's very natural to have one component define the list, and child components define each entry in the list. Something like React makes this trivial.
On iOS on the other hand, you are encouraged to use a UITableViewController with UIViews for each cell. This immediately pushes you towards one mega-controller which mixes the responsibilities of the list with those of the individual cells. To overcome this, you could try to have a UIViewController for each cell (uncommon), or have the UIView of each cell start taking on more responsibilities of a UIViewController (breaking MVC).
In general though, iOS's MVC is a perfect storm of being both bare bones as well as opinionated at the same time. For these reasons many large corporations have moved away from MVC to their own custom in-house architectures to handle scale.
Facebook - https://www.youtube.com/watch?v=mLSeEoC6GjU. * Uber - https://github.com/uber/RIBs * Square - https://github.com/square/workflow
Eventually, we bought a house. It felt like a huge shift from the vagabond lifestyle, but I don't regret it. We still travel a lot, and rent our house out on AirBnb while we are gone.
I think in the end, traveling full time was too much for me. Having a home to go back to and recharge before planning the next trip seems more balanced.
Looking at the numbers on a smaller scale, if you don't count the unlimited wine, the monthly quota works out to be about 2.2 drinks / night - about 1.5 shouts of liquor and less than 1 light beer a night.
Thats a pretty resonable amount of alcohol to consume - just slightly higher than the 14 drinks / week maximum that many health authorities recommend.
How would you feel if the government regulated how much sugar or salt you can eat, how many hours of video games you can play, or maybe even forced you to exercise 400 hours (per year)?
Now imagine if your office moved to a tiny, faraway town with no food, nightlife, or dancing. Does remote work seem more appealing?