gregkerzhner

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.

Same here. I subscribe and then immediately cancel, which stops the recurring billing but lets you use the service for the rest of the month.

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.

If it’s during open hours, you can always walk inside the store and buy gas from the attendant which should let you use your card without a zip.

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.

Oxymonad?

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"

Chick-fill-a might be a bad example given their history with LGBT folks.

https://en.m.wikipedia.org/wiki/Chick-fil-A_and_LGBT_people

https://m.youtube.com/watch?v=g-NsgOa42VE

Here is your world of underground freeway biking btw

Eerily similar experience here. I came to the US from Russia at the age of 9 and slowly watched my Russian slip away. 23 years later my vocabulary sucks and I have a strange accent.

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.

"A cover letter is a written document commonly submitted with a job application outlining the applicant's credentials and interest in the open position"

Sound suspiciously like a "paragraph about why we should hire you"

Curious - does TikTok censor content that China would find sensitive, like the existence of Taiwan or pro Hong Kong protest content?

This statement "we don't usually care if you don't know find the perfect algorithm (unless it's for a senior position)" made me chuckle.

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."

How do you manage data flow from your view layer to your API layer? Like for example, if a UITableViewCell has a button in it which needs to load some data from the API? Do use an event/delegate which flows from the UITableViewCell through the `cellForRowAtIndexPath` method to the controller, out to some other class? It must feel pretty great to have your business logic and API layers abstracted into other classes, and have your lean view controller just be the glue. Yay MVC!

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.

I fully agree here - MVC scales terribly. Of course, it's not impossible to come up with a well designed MVC app at scale, but it takes a ton of skill and feels like you are fighting the framework at most steps.

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

I’ve been commuting on the extra light Rene Herse tires for about a year in the city and haven’t had a flat. They are set up tubeless though. They are a joy to ride and greatly improved the speed, comfort, and handling of the bike. I was hesitant to get them because most of my riding is on city roads with debree, but haven’t regretted them at all.

My wife and I did this for 7 years as well. I had a strict "one item in, one item out" rule where for each new item we acquired, one had to be let go. She was not fond of this rule, and I can't say we followed it fully, especially as her photography career (and the amount of equipment it required) took off.

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.

Annually? Everything sounds high when you say it annually!

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)?

Thats great that you work and play in the same location, you are lucky!

Now imagine if your office moved to a tiny, faraway town with no food, nightlife, or dancing. Does remote work seem more appealing?