turdprincess

One other important tip - cross reference with google maps for things in the surrounding area that might annoy you. This might include * busy roads * buisnesses * churches (learned this one the hard way my last trip to Greece by renting a place next door to a church. The bell would be so loud that I would jump every time it rang).

But wouldn't they basically have no choice but to scale up their own workforce if their client's business is booming? It wouldn't be a good look to say "hey actually we can't take your project on because we believe a recession is coming".

Consulting could be even more "boom and bust" than normal companies since consulting budgets might be the first thing to get cut when times get tough.

Ive been in some "mixed" sessions lately where some are remote and some are in person and its the worst case scenario. I feel like a second class citizen when someone points a grainy laptop camera at a whiteboard they are drawing on. The second I can't grab a marker and contribute, I just lost my full ability to participate.

Fully remote works great - there are plenty of awesome collaboration tools (Miro for example) where you can collaborate. Fully in-person obviously works as well.

But with hybrid, someone always loses - either the folks in the room or the folks on the screen.

To be fair, this is something that hotels do as well. Ive been traveling to NYC a lot recently, and I consistently find that the nightly price seen in the search is usually about 20% less than the final price I pay due to taxes, fees, and resort fees.

Depending on the severity, its not unusual to get 8 doses for the most minor of cases, like a root canal.

It's crazy how eager American doctors are to prescribe opioids. Over the last few years, Ive gotten narcotic painkillers for serious stuff like surgery, but also for more minor stuff like dental work or joint injections. In most of those circumstances I would take one or two of these pills and then be just fine with non-narcotic over the counter pain medicine. But every time, I am highly encouraged to take the narcotics "just in case" the pain gets bad.

The "work from home" part of WFH isn't the most important thing. Its actually a downside - I would love to have a nice office to go into a few times a week where I could chat to coworkers.

The real benefit is that your market for possible jobs expands nationally or even globally. For my current job, there simply isn't a job like it in my home town, and if it wasn't for WFH, I would have to move to California. I think there is something to be said for including folks from other locations into the cutting edge of tech.

I think a lot of people would object to a system that reported every detail of your life to the IRS.

The government can’t magically know what your expenses and deductions are. Got married, had a baby, used a home office, paid a plumber to fix your rental property? Deducting mortgage interest?

If none of these things apply to you and your taxes are really just a single w2 income it’s pretty simple to just fill out a paper 1040 form (or even 1040ez). You just need your w2 and an hour of time.

In my town craft 4 packs of beer cost 15 dollars, or about 4 dollars a beer. I have 1 a night, which easily brings my cost over 100 a month. I don’t consider myself an alcoholic.

It seems like the thing to do is to downsize offices until they correctly meet usage. So, take your number of employees, multiply by percentage that usually comes into the office, add a buffer for growth, and have an office for that.

My vision for a "traditional" IC is someone who sits in front of a computer and writes computer programs. This kind of role ends at senior, or if you are lucky, staff. A principal engineer is much more likely to be in a meeting heavy environment, coordinating with many teams and driving alignment towards some vision. While this is not strictly managerial work, at least to me, it seems to fall much closer to "senior manager" than "software engineer".

Thats totally fine for folks who thrive in this kind of role. However, it does take away the ability to grow your career if you want to keep developing software. So for example, if you program for 20 years, and keep improving during this time, you would expect to be rewarded with some career progression for the progress you've made in years 10 - 20.

But as it stands, these days, if you run into someone who has been programming for 20 years, you can assume their career has mostly stagnated, and might even count them off as a low performer because they failed to grow. So it's almost a self fulfilling prophecy - staying a "true" IC has no growth, and therefore there is an incentive to just sit back and stop growing.

The principal engineer role usually comes with expected impact on a big organization or even the whole company. Having that kind of impact is impossible as an “IC” in the traditional sense. Unless you are in some very cutting edge area, or get very lucky, your principal role will involve a big dose of the same leadership and management tasks that a manager or director would have.

A wide mouth Nalgene or whey protein container work well for both ladies and males. I’ve never heard of anyone using a diaper. Pee only of course.

Could folks be optimizing for the wrong thing? I feel like there are plenty of 3 person startups where you can code your face off without red tape or human interaction. However, such gigs come with lower pay and worse work life balance.

Personally, I made the choice to join big tech and collect a bigger check. The work can be slow and boring, but it's a conscious tradeoff I am making - money instead of fun.

In my experience, codebases never maintain their level of quality. Unless you are taking deliberate action to improve the codebase with every commit, it's actively getting worse like you described above.

The interesting thing is that this isn't a technical problem, it's a human problem. Most folks want to clock in, do their job and clock out, and going the extra mile to improve things isn't worth the effort.

I think its the same human tendency that leaves so much pee on the toilet floor - some humans will clean up their own, but almost none will clean up someone else's.

I think in the end, it's hard to separate technical leadership from human leadership. After you do your system design, you need to divy it up amongst the juniors to get it implemented. When deciding who gets what piece you have to consider what motivates them, what their strengths and weaknesses are, etc... But for sure your manager is helpful in figuring these things out.

At this level, your manager basically becomes your partner, with the same goal of getting the work done most effectively. Your domain is the technical, their's is the human, but there is ton of overlap in the middle

Unfortunately you will either need to change your attitude or change teams. In your position, the expectation is that you are mostly a working through others and acting as a force multiplier of their work. So doing stuff like:

* figuring out what motivate your juniors and trying to align that with what needs done

* giving them work which stretches their abilities but doesn't overwhelm them

* giving them some space to fail but not too much

* grooming your juniors to be leaders themselves so they can do some of this mentorship

And in general, there are two ways to go. The first is to accept the fact that many senior engineering and most staff engineering gigs are more about this kind of mentorship approach than actually doing work. And basically accept that the prime "getting shit done" years of your career are done and you will mostly be working in this new way now.

The second is to change jobs where you are back in the driver seat. As a senior engineer, these positions DO exist even at FAANG (over on my team, I am the most junior with 12 years of experience). However, the more senior you get, the harder it is to find a role like this, especially in big tech - its the rare exception. Startups and consulting gigs probably better align with wanting to be hands on keyboard, but at the price of a paycut.

It’s also plausible that the function used to do x,y,z in that order, but then a new requirement came to do z before y. The code was changed, maybe a test was even added, but the comment was never fixed.

That’s the problem with comments (and all documentation really) - it gets stale and has no guarantee of being correct.

A better way is to write a test which would break if the order of x,y,z was wrongly changed. This way the order is guaranteed to stay correct forever, regardless of any comments.

Maintenance work can easily be negotiated at this schedule. For example, you can launch a project, and then stay on "retainer" for 5 hours a week for bug fixes. If you find a few projects like this it could meet your criteria.

With new feature development it would be harder. But you could negotiate a weekly fee based on a 4 day work week, and then get so good and efficient that you do the work in 3 days.

What is the better kind of client / project then, out of curiosity?

The pay is an unequal comparison though. A W2 job gives you:

* 5 - 10 paid holidays like Labor Day, 4th of July, etc...

* another 10 - 20 paid days off for PTO

* 7% less taxes for social security, medicare

* 401k match

* health insurance

So actually, getting paid twice as much hourly might not be too much extra at the end of the day.

contacted for many years as well. All my contracts always ran a year or longer. In the end, it felt very similar to full time employment - it was 9 - 5, regular meetings, coworkers, etc.. At the same time, I didn’t get any benefits, health insurance or paid holidays.

I am not sure I want to contract like that again. It has most of the downsides of regular employment but none of the benefits. I think in the USA it would make more sense to just switch full time jobs every two years and take breaks between.

Id love to try contracting again but more like true “consulting” - higher rate and fewer hours. I am not sure though that pure dev work could be high leverage like that - it just takes too damn long

My issue with Xcode isn't a lack of features, its the fact that the features don't reliably work. And not the advanced stuff, the very basic features. I routinely have issues with stuff like clicking through classes or syntax highlighting.

Another thing thats highly annoying is that compile errors don't get properly cleared on builds, so if there are multiple errors, it might just be that one of them is a real error, but the others are stale.

Lately I've been working with Swift Packages, and now restarting Xcode many times a day is part of my workflow - otherwise compile errors persist.

Ive been in iOS for a decade now, so mostly I don't get hung up one these issues, I know how to clean the "derived data" folder, I know how to jiggle it "just so" to get it to do what I want. But still its frustrating that the most important tool in my job is doomed to be moderately broken forever.

It might be a "grass is greener" scenario, but whenever I hop to IntelliJ, I don't encounter any of these kinds of problems.

Oh, and BTW, if you want to check Xcode out for yourself and have trouble downloading it, its not you - Xcode is like 20GB big. I guess you need lots of space for the world's most broken syntax highlighting algorithm...

That’s a fair point. I think it’s interesting that the bar for getting a job is so high, while the bar for keeping your job is so low.

I think what might be happening is a vicious feedback loop of

* companies hiring too many smart engineers

* those engineers are in turn very bored and don’t have much to do so they check out

* not much gets done so more people get hired to do more stuff.

I think the problem these days is that it’s so hard to fire someone. I’m not sure if it’s legal, cultural or otherwise, but I constantly see coworkers who are at best useless and often detrimental being kept on and on and on.

So the game becomes to avoid hiring someone like that at all costs, because once they are hired they are impossible to get rid of.

I wish employment was more like contracting - you give someone a trial for a few weeks and then end it it’s not a mutual fit. No long interview necessary - the job is the interview.

I’m not sure about relative fraud numbers, but the fraud refund differences are real. With a credit card they will refund you basically no matter what. With a debit card it’s much more hit or miss - I recently had 3 fraudulent transactions on my debit card for about $100 each and they refunded only one of them.

That’s crazy if you think about it - you give your card around to many people and any of them can write it down and use it.

In the US the only sensible thing to do is to use your credit card for everything and keep your savings tucked in an account which doesn’t have a card at all, nor a checking account tied to it. Then maybe a small checking account at some other bank for rare times you need cash.

Swift is great. I’ve done a lot of it, but also bounced around between Typescript, Elixir and Java and every time I miss Swift’s strongly opinionated, highly descriptive and flexible style.

Also, for the most part, it’s vastly superior to Obj C. The sad thing is that when writing Obj C I often find myself not writing the clean, well structured solution that’s in my head out of sheer resistance to the verbosity that it would take. I always just keep thinking how simple it would be in Swift and how much longer and more keystrokes / files it takes in Objective C.

At least at my school, the CS degree was open ended. You take a handful of required corses (intro to programming, algorithms, operating systems) but aside from that, it was up to you to pick the classes which interested you. If you were interested in security, or databases or mobile app development, you could take those classes, but they weren't required.

The things I learned in college which were actually applicable to a software engineering job was:

* A basic ability to program

* Maybe some low level concepts about operating systems. But this is a big maybe, because my operating systems class was pretty early on and was long forgotten 3 years later when I went to apply for a real job.

I learned nothing about version control, the typical client-server model, html/css/javascript, REST, servers, databases, doing a pull request, teamwork, etc. I think those classes may have been available, but I never took them and graduated just fine.

I am not convinced this 4 year CS degree was any more useful than a bootcamp, which teaches you the actual useful things you need to be a junior dev.

I think the difference between CS and a bootcamp is more of intent and followthrough. People often pick bootcamps because of promises of easy money, versus someone who does a 4 year CS degree is possibly more committed and won't give up as easily. But in terms of their actual preparation, I doubt one is better than the other.

I have a CS degree from a top university and I didn’t learn any of the above in college (except for perhaps debugging), including an internship.

Actually 10 years later I’m a senior engineer at a FAANG (mobile specialty) and I still don’t know most of the things you listed. Except for debugging - I got that down!