gregkerzhner

I think small teams, one on one collaboration, and interesting projects are key.

It’s hard to get to know folks when sitting on a big zoom call, but I find working one on one works well for developing a bond.

Once you spend many hours over many months working closely with someone, a bond develops and there is plenty of opportunity to get to know them along the way.

In fact, you can do this just over slack - spend enough time hanging in a chat and people’s personalities are bound to come out.

To be fair, you may be less likely to make a very close friend with a remote employee. But a friendly, productive working relationship is certainly easy to develop, and that’s all that’s necessary for most teams to function well.

This strategy probably wouldn’t work with big teams where folks float in and out, or for roles where you have to meet new people all the time.

Curious, do the members of your team have activities, hobbies, and relationships they are involved with outside of work? From what I have seen the folks itching to get back to the office are the ones that don't have many outlets outside of work.

On the other hand, for many of us who do have significant non work passions (rock climbing for me) as well as social circles around these activities appreciate remote work because it allows us to structure our lives in a way where such activities coexist with work more easily.

The interesting thing is that for work centered people, remote work has reduced social connections, while for more interdisciplinary folks it can do the opposite.

I have personally worked 100% remote for 7 years now, but before that I lived and worked in San Fransisco. I never attended a Friday night work happy hour because every Friday night I would be in the car driving 4 hours to go climbing in Yosemite.

Now, I can work remotely from a town with great outdoor access and spend my Friday nights hanging around with local friends instead instead of in the car.

Remote work has allowed me to have a more balanced life filled with more things I want to do and less I don't. Have the years of video meetings made my professional career less productive? Perhaps, but I have still worked on plenty of cool projects with plenty of great folks along the way. Some of them have even become close friends. And even if it has suffered, its been worth it!

I would love to see stats on religious prevalence and incidence of crime, homocide, etc. My guess is that such stats won’t put religion (especially Christianity) in a favorable light.

Same thing here. It's much easier to demonstrate competence for an afternoon of interviews than for a few years of real life projects.

Nice, I was genuinely curious about this, and it seems like a solid strategy!

This. Curios to hear about people's experiences owning an EV without access to a charger at home.

Even if your schedule is flexible, other people's schedules aren't. This means that if I want to shift my schedule to wake up earlier to take advantage of the morning light, I either have to miss out on evening social activities (lets say an 8pm dinner), or miss out on sleep.

Hey now, I never said I wanted anything! But it's hard to believe that removing the elites from power is going to be a simple reform. The most powerful, established and connected people in government aren't going to simply walk away, it would take a major disruption.

A few things here:

1. Background check companies usually only contact the positions you list to verify your dates of employment and title. They probably won't contact a job you don't let them know about.

2. If it helps you sleep at night, you can still fill out the background check form accurately, but leave stuff off your resume / not talk about it in the interview. Again, there is no rule that you need to talk about every job you have ever had in chronological order on your resume or in the interviews. As long as there is nothing untrue, or some sort of strange conflicts of interest, you are totally welcome to omit things that aren't relevant.

3. In the rare, extremely unlikely chance that you have to explain yourself, it seems perfectly acceptable to say "I've only been at this job for a few weeks. I am not sure I am going to stay longer, so I didn't think it was relevant".

If you are interviewing for the CIA, then definitely list every job. If it's a normal tech job, people simply don't care. Fill your precious chance to impress your interviewer with things that are actually impressive.

"When I started my second job search, I was worried that the short tenure in the job I was trying to leave would be a turn-off to perspective employers. In reality, however, it wasn’t a big deal- people asked about it, but seemed satisfied with my 20 second summary and then moved on to other things."

Alternatively, you can simply leave your new position off your resume and not talk about it in the interviews at all. There is nothing wrong with saying "My last gig was a software engineer at Stripe. I left there to focus on looking for a better fitting opportunity".

There is no need to have your resume be a complete record of your employment. In fact, such resumes are often less desirable because they are long and don't highlight any specific strengths. Instead, make your resume highlight your most relevant and best accomplishments.

I've only been a professional for 10 years, but I am already condensing my resume, removing descriptions from my first few jobs. I imagine that as time goes on, I will even group jobs together like "2010 - 2015 - Software engineer at Companies A, B, C" to keep my resume a nice, neat one pager, and focus on the more important things I have done recently. Like the OP, I've also quit two jobs shortly after I stared them during my career and those are definitely not on the list - its simply not relevant.

I would say that Trump's ability to convince people he is knocking down the elites, and instead using the office to benefit both his elite self and his elite inner circle is his greatest hustle, but actually, its quiet an ordinary move that elites have been pulling since the start of time.

I feel like to really knock down the elites, you need someone who is not elite. However, anyone who rises to this kind of status by definition becomes elite even if they weren't before, so it's kind of a self fulfilling failure. True revolution can probably only come from many non elite people seeking the same goal. This kind of revolution would most likely be squashed by someone elite.

They forgot the most important rule of Core Data - just don’t use it!* The amount of problems and nuances it creates is simply not worth the functionality it provides.

*If your app manages huge amounts of records on the device, then it might be worth it. But that’s not what many apps use Core Data for. Many apps use it to cache bits of data from the server and other local state. You don’t need a full blown ORM / database for this. Instead of wasting your time learning the obtuse Laws of Core Data, model your app state with some nice Codable structs, write it to disk, and then take the afternoon off.

As a counterpoint, for a project of decently large size on my 2019 MBP, IntelliJ is snappy and a delight to work with, while Xcode takes up 30 GB of space, takes minutes to boot up, and gives me syntax highlighting and autocompletion about as reliably as a broken clock tells time.

To be fair, if you unit test your objects, there are usually two implementations - the real thing and a mock. If you have a solid mocking framework, that can alleviate this need.

As a non smoker, I've always found the actual smell of a burning cigarettes to be sweet and attractive. I think this is because some of my earlier memories are being a little boy waiting for the bus in freezing cold Russia, and seeing soldiers smoking. It looked warm and pleasant, so I think I associated the smell with pleasure.

Places with stale smoke, like bars and smoker's houses still smell bad though. Its the actual smoke from a cigarette that I like the smell of.

What’s wrong with the new 1x gearing? It’s pretty standard these days in mountain and gravel bikes. As long as the back cassette has a varied range you don’t lose too much gearing while getting the benefit of a simpler drive train, less maintenance and lower weight.

(My opinion should be taken with a grain of salt because I am a grumpy, antisocial basement dweller) We tried something like this at my work. The few days it was happening were some of my least productive in a while. Doing work while having a live camera pointed at my face all day made me nervous and unable to have deep thoughts. On top of that, there was constant noise coming from my headphones of other people's conversations.

My immediate response was to shut off my camera and drag my icon all the way to the corner of the screen so I can work alone. If the goal is to reproduce the distracting nature of the open office, I gotta say projects like this are a huge success. Also, streaming live video all day every day for no reason seems like a waste of resources on all parts.

I can see how this would be a cool tool for normal social events like parties and conferences though! Just not every day work please.

Just out of curiosity, how long have you been in Bend? My wife was born and raised in Bend and left in her mid 20s. Due to our out of state license plates and IDs she gets a fair amount of "please don't move here you out-of-stater" gruff, and it always feels silly coming from folks that themselves moved here for exact same reasons that the newcomers are flocking now.

We are doing something similar on my project except using the J2OBJC compiler. The compiler is a cumbersome, unwieldy tool, but the cross platform approach overall is great. We write the core logic of our app using the cross platform approach. Platform specific APIs like geolocation or maps get handled natively, but pass their data off as inputs to the cross platform implementation. So for example, you wouldn't render a map natively, but you could write a handler for an updated location from a map, or query the network based on the current map area and return some results.

An added bonus of this approach is that it forces you to have a clear separation between your user interface code, and your business logic. A lot of mobile (and front end) apps out there have no architecture, putting API calls, state management and UI right next to each other in the same modules. Our approach forces you to keep UI code just focused on UI, while keeping all logic somewhere else, where it can isolated and as a benefit much more easily unit tested.

You would be surprised just how large of a share of your codebase can be moved into platform agnostic code if you have a solid architecture. Our UIs are "dumb" and render themselves from view models which have exactly the data needed to render the view. All the logic and state management to construct these view models can be written in the cross platform repo and shared across the Android and iOS apps. For example, to render a list, you will need to use the native UITableView or RecyclerView separately, but all the code that manages how many rows are in the list, the data each row needs, as well as updating the data when the list is reordered can be shared across platforms.

Same story here (parents came to the US with 3 kids (I was 9)) and struggled to support us (initially by being dishwashers at the local buffet).

I got a good college education and have a cushy software gig. Now I sit on my butt all day drinking LaCroix watching the checks come in. I sure as hell consider myself privileged.

Just because you started out lacking privilege, doesn't mean that you don't have it now.

For me, personally, part time work would be the dream. I used to contract and would do year long projects and then take large multi month breaks between. Neither "mode" was optimal. Work periods are obviously stressful and its hard to find free time. But the rest periods also got a bit old after a month or so, and even when we were traveling to cool places, I would find myself grabbing the laptop and coding just for fun and to keep my skills sharp. A part time scenario seems like the perfect in between.

However, I never saw a place where it could work. For one, if the rest of your team was full time and you were part time, you would automatically be less productive and useful than the rest of your peers.

With your Monday / Friday scenario with no meetings, it seems like the people that only worked Tue - Thur would have their schedule disproportionally filled with meetings, and have much less time to get stuff done. This could work for a manager type role, but it wouldn't work for an IC.

I feel like part time work, much like remote work, might require an all-in buy in from the whole team. I wouldn't be surprised if in the future companies go "all part time" and have their whole organization be tuned for part time productivity.

I think for part time to be successful it has to be the right environment. Contract work seems perfect - you are focused and have a singular mission. I can also totally see working on a personal project 20 hours a week and being super productive.

However, working part time for a large organization seems tricky. There are so many meetings, distractions, and responsibilities other than just coding that it seems like your actual focus time to do work would be pretty nonexistent in a part time scenario.

The agility is still there, its just buffered a bit. This is really useful for concentrating. If you are in a small startup with obvious goals, I don't think you need sprints. If you are in a large organization and are constantly being pulled into different directions between new feature work, production bugs, and tech debt initiatives, having a buffer is pretty useful.

Without sprints, when the next semi-important bug comes down from production, its pretty hard to justify that its more important than the feature you are building, or especially the tech debt cleanup you are doing. Everything tends to be "important" so if there is no culture of picking a set of work and sticking to it, attention is constantly distracted from one thing to the next.

For me at least, programming is all about some momentum - its hard to get rolling but once you are, you can keep going. Sprints give me the room to have bouts of momentum, stopping every two weeks to adjust direction, and then starting up again. Without them, it feels more like pacman - darting and reacting rather than holding a steady direction.

One thing that I didn't realize I loved about sprints until I went to a place without them is the guarantee what for the next two weeks, your priorities are set, and aren't changing unless something very unexpected happens.

Having a two week period with a decided set of work allows you to peacefully do this work isolated from incoming requests - unless they are critical, they will always be delayed to the next sprint. Without sprints, our direction and priority changed daily, with no ability to say "we haven't planned for this, please wait". The result was it was incredibly hard to get anything done, and attention was always scattered.

I am happily back at a place that is doing sprints, and I am sure the problems at my previous organization were far bigger than not having them, but sprints do seem like a great tool to isolate the developer from exterior fluctuations. Granted, a great project manager can probably do the same thing.

I want to know what kind of signals they are getting from your temperature preferences. Something like "wow, this person keeps their house hot, let's send them marketing for vacations in the tropic?"

Interesting article. We use a similar approach for our mobile apps to allow multiple teams to develop their own modules independently.

Can anyone speak to what the advantages and disadvantages to such an approach are as opposed to going full Kubernetes / Microservices? Is it that deploys are riskier and you can't scale separate pieces independently?

Why the downvote?

We use Google hangouts at work and it.... works just fine. What is the big deal about Zoom?

The problem with Apollo is that if you use it for server queries, you are basically forced to use it for local state management as well. This is because server state and local state is usually intermingled, so its not practical to have a Redux store for local state and then use the Apollo cache for server state.

This means that Apollo is essentially incompatible with Redux unless you are willing to duplicate the data in the Apollo cache into your Redux store. Such duplication is a waste of resources, and also defeats the point of using Apollo to begin with, since you are circumventing most of its feature and just using it as a plain GraphQL client.

I think Apollo is trying to do too much, and a much better architecture is not to couple your GraphQL query infrastructure to your state management infrastructure. This can be done by using a more low level GraphQL client and then choosing one of the many amazing state management libraries out there in combination. This way your GraphQL client does not dictate your state management layer.

One thing that drove me crazy about using Apollo for local state management is that you have to manually fetch, update and save the data on every change. For example, if you have a list of items and you need to add one, your mutation would need to query the store for the list, add your new item, and them write the mutation to the store.

This adds extra overhead on every single mutation as opposed to Redux, where your the current state is automatically passed into your reducer, and you don't need to worry about writing anything after you update - the store handles that itself by updating the state to the result of the reducer.