akamia

I worked with a team that owned a service that resizes images. An engineer was assigned a task to add support for auto rotating images. His solution involved saving the image to a file and then using a library to handle the rotation. He used a hardcoded value for the file name. In a local environment where requests are sparse this looked fine to him and other engineers on the team missed it in code reviews. It wasn't until it went out to prod that he realized the error in this. Users started seeing other users' images because the file's content was constantly being overwritten.

When you test features like this or caching a response with a JWT it can be very easy to default to the happy path or ignore the impact of a large volume of concurrent users.

I used to work in IT at a Fortune 100 manufacturing company. IE versions hung around for a long time because there was a lot of software that was built with only IE in mind and only received the bare minimum of support.

In some cases this was off the shelf software from vendors who had gone out of business. In other cases it was software built in house that would require a complete rewrite to modernize.

All of this software was tightly integrated into processes that were critical for the company to operate. While the cost of replacing the old software was a consideration, the biggest concern was the potential disruption to operations.

If a software change reduced productivity or even worse caused work to stop entirely, it meant millions in financial impact.

This is definitely true but it doesn't hurt to ask. I've asked every time and gotten some really useful responses.

When I was young I interviewed at Microsoft and was rejected. I asked the recruiter for feedback. She talked me through some of the feedback from the interviewers and gave me advice for the future. It was really helpful.

This was also really common with TVs during the Super Bowl. People would come in and buy the biggest TV they could get, have their Super Bowl party and then return the TV.

The last time I was at a start up (~2 years ago), it was a running joke that the easiest way to raise money was to say your product had something to do with AI. We saw so many companies that were branding everything as AI simply to raise a round.

One of the funniest cases was a start up that claimed to be using AI to process their customers' requests but was actually just farming out the work to contractors who were doing everything by hand.

It doesn't necessarily have to be that expensive. I have a friend who recently went through a very friendly divorce. Both parties had agreed on who would get what. In Washington State there's a process for these types of amicable divorces where a judge doesn't have to make any of these determinations. They had to pay the ~$500 filing fee, wait 90 days and that was it.

I'm sure it varies quite a bit from state to state though.

Not really. Longevity and financials were how we identified stability. If the company had been around for a while and/or could demonstrate that they had enough runway to last for a couple years, then we considered them stable.

We had enough experience with startups who would sell one license to a big company and then throw their logo on the slide that knew the logos didn't mean anything.

When I worked in Enterprise IT evaluating new products for a Fortune 50 company it was pretty much the same way. The three biggest things that we looked at were functionality, support and the stability of the company.

We needed to know that it could do what we needed it to do and that there were enough support resources that we could get someone on the phone if we had an emergency. It is not cheap to integrate new software into the systems and processes of a large company so we also needed to know that we weren't going to put in that effort and then have the company go under a year later.

Support and stability were the two biggest issues that limited adoption for early stage startups. We didn't care if you had any big name customers. We just needed to know that your product did what we needed and you'd be able to support us for the long term.

When I worked for Boeing there was some critical factory equipment that still ran on Windows 95 and even Windows 3.1. IIRC, the manufacturers had gone out of business so Boeing actually fabricated parts as needed to keep them running.

I was there at the same time and I remember the exact same thing. There was a lot of talk about this being used to offset some of the losses caused by any future union strikes and also as leverage when negotiating with the unions.

I also remember that there were consistent ongoing quality issues. Planes from SC would require significant rework when they arrived in Everett.

When I worked at Boeing, we even had them on the windows of offices that weren't being used for government projects. The company's commercial business was also a target for spying so they were very protective in general.

To this day, the company's laptops don't have cameras and they have a whole process that you have to go through to use a camera anywhere on company property.

The problem with this approach is it also assumes that overcoming the virus means a return to 100% health with no long term impact. We're already seeing that it can lead to other long term conditions. I have a friend who is being treated for heart damage after having COVID.

I'm in a low risk population but just because I'm not likely to die from it doesn't mean it's completely harmless to me.

I can definitely see that happening more often. If you're not required to be in a certain office location, that opens up a lot of options for other cities.

I was disagreeing more with the extreme opinion that some have that remote work would cause these cities to become desolate. Would some tech workers leave? Definitely! Would they all leave? I doubt it.

I've noticed the same thing and especially in tech. I have a few friends who are engineers and have this idea that if everyone went completely remote, cities would clear out as everyone rushed to buy acres of land in the country. I always find it a bit funny that these friends are also the ones who seem to have the most city oriented lives. They are going out to bars and restaurants all the time. They get their coffee from local artisanal coffee roasters and their beer from the many local microbreweries. They don't seem to recognize that the cities they think people want to flee offer more than just career opportunities.

I worked with a guy who used to live in the area and he also had an interesting perspective. He explained that there were many people who lived in remote homes that needed to have water, fuel, etc. trucked in from town. Sometimes they would encounter one of these people half dead. They'd had to waste some of their limited resources helping them get to safety. This led to a lot of anger.

I would add that anyone who is planning on moving into management should also avoid joking like this.

I once worked with an engineer who had a lead that would joke all the time about firing him. As a lead he had no authority to fire anyone but it was well known that he wanted to transition into a management position. Within two weeks of the lead actually becoming a manager, the engineer left the company for another job.

I remember speaking with the engineer about it after he left and he told me that he knew it was a joke but it still made him slightly uneasy. He wondered whether there was some grain of truth in the jokes. He wanted to make sure that he was leaving on his terms.

The take away that I took from that was if you're going to go down the management path, consider everyone a potential direct report and communicate accordingly. The joke that you're making as peers can take on a different meaning the day you become their manager.

I once worked at a Fortune 50 company where keeping your budget low was something that upper management (at a certain level) was not happy with. We once built a hadoop cluster because we needed to "burn" some money (~$150k) left in our budget. In this company coming in under budget meant you didn't do a good job of forecasting your needs so you were punished with budget cuts the following year. That led to so much waste. Coming from a startup where saving a few hundred dollars/months was something to celebrate it was mind-boggling to see all of the waste.

You also miss out on the community aspect of things. Working with a framework like React means that there is a worldwide community of developers that you can tap into when you run into a roadblock.

It is incredibly frustrating to run into an issue with a home grown framework and have to ask around only to discover that the person who wrote the part you're having trouble with left the company 2 years ago and no one else understands it.

Sometimes this happens if the employee falsified information on their background check form to avoid being caught in the background check. Some companies run a quick high level background check but also have longer term processes for in depth checks.

I once had a similar situation happen at a very large (150k+ employees) company. Security showed up and escorted one of our contractors out the door. It turned out he had worked for the company previously and stolen documents that he used to try to extort money from the company. When he was being brought in for this contract position he had changed the spelling of his name on the form and used a social security number for someone with that spelling. During the quick background check everything looked good but the discrepancies were discovered during the more in depth check a couple months later.

Boeing has done this voluntary offer several times. The goal is specifically to entice people who have 25+ years of service and are at or close to eligibility for collecting their pension.

When I worked there I had coworkers who were ready to retire but were hoping for one of these rounds so that they could get a little extra on the way out.

> There is no telling if it will actually save time. You could be messing with configurations, have to learn their docs, etc... Or future migration could be expensive in both time and money.

Sure. Every situation is different. This isn't meant to be universal. There absolutely are cases where rolling your own may be more efficient. However, my argument wasn't that existing solutions are no effort, just that they are often less effort than trying to do something completely custom or self managed.

Regarding future migrations, the same can be said in the opposite direction as well. You may get to a point where you need to migrate away from your custom solution to something more standard and you'll face similar time/money issues.

> Custom is more configurable.

Sometimes this is the case and sometimes it's not. Sometimes custom is very narrowly focused and as new use cases emerge requires significant rework.

> People overestimate their time worth? Sure you can theoretically work for 75$/hr, but can you get overtime/additional revenue that easily?

The number will vary for everyone. $75 may be too high for some and too low for others. If you're an attorney sacrificing billable time to do something administrative that could be outsourced, $75 may be low. The idea is to tie an actual realistic number to the value of your time.

> What is your value add? If it's software, I might suggest custom is best because that's your business. If you mash a bunch of software suppliers together, you become a middle man. I'm not saying that doesn't work, but I've seen companies go back and forth on this.

In software, I think it's important to know what your product is and to focus on your core competencies. I've seen lots of engineers decide that they need to build something from scratch that doesn't directly relate to their product. Could you build your own credit card processing system? Sure, but unless your business is credit card processing, it probably makes more sense to use something like Stripe. The same goes for lots of different aspects of your product and business.

I'm simply suggesting that you have a limited amount of time in each day and you should do what you can to get the most value out of that time. Don't ignore the value of your time and sacrifice it needlessly.

One of the problems that a lot of engineers have is failing to recognize that their time has a cost. Spending 4 extra hours of your own time setting up a mail server that will cost you $5/month to run instead of paying $10 per month for Office 365 or some other service is not really saving you money because that initial 4 hours of labor is time you could've spent doing other things for the business. It's not free time.

I find it really helps to put a dollar value on an hour of my time. In that context, if 1 hour of my time is worth $75 and I've spent 4 hours setting up this mail server, I've spent $300 on my labor in addition to the $60/year for the cost of the server. Obviously this doesn't work in all cases but it really helps me determine when it's worth it for me to spend my time doing something and when it's better to outsource it.

You're required to keep the dog in the bag under the seat for the entire flight so they shouldn't really affect cleaning.

I have two issues with the fee.

1) It only covers one way. For a round trip itinerary you are looking at $250 - $400 for the pet fee. That can be more expensive than the actual ticket.

2) Your pet counts as your carry on item. I would be a little less bothered if the dog was allowed in addition to your carry on and personal items or if the airline included a free checked bag with the fee to offset the carry on. Since the dog counts as your carry on, you have to pay an additional $25+ each way to check a bag you might've otherwise carried on the plane.

Definitely! My credit union (BECU) actually refunds ATM fees which is an amazing perk. Before I was with them I would try to look up ATMs without fees ahead of time but that can be pretty tricky and inconsistent (especially outside of cities).

Yeah. That's pretty frustrating. I always try to make sure that I have at least one card that doesn't have foreign transaction fees and I stick to that card I'm out of the country.

That's been my experience as well. Using credit cards when possible and withdrawing cash from ATMs are the two best ways to get a good exchange rate.

It's a little hard to know whether this is reasonable or not without knowing more about the circumstances (dollar amounts, is this change your decision or theirs?).

I haven't experienced it personally but I've had friends in similar situations. It's not uncommon for traveling roles to have additional incentives.

I worked for a company that regularly added an additional percentage to your salary if you were on a temporary relocation or were regularly traveling for your role. This was to account for the inconvenience of being away from home, family, etc. When you returned home permanently that percentage was removed.

I would ask if there is a documented policy discussing the compensation differences between traveling and in office roles. A company of the size you mentioned should have a policy for this kind of thing. Understanding the policy should help in your communication with HR.

I think often what you'll see on the IC side is above the Senior level (Principal, Distinguished, Fellow, etc.) there are fewer available roles. I've been in organizations where the highest level you could go is Distinguished Engineer and each VP would have one Distinguished Engineer and several Directors. Using your example breakdown, there are 8 possible director positions under a VP while there is 1 possible DE position under the VP.

Additionally, it can be easier to transition to an equivalent or higher role from one company to another on the management side. Most companies are open to hiring a VP from outside but often the highest levels of IC roles are only filled by those with significant experience within the company.

I had the same thing happen.

When we were discussing me joining the company there was a very clear plan for the product and the path to revenue. Unfortunately, he had one meeting that completely shook his confidence in that direction. After that meeting it was something new every week.

We would build the feature of the week and then it wouldn't immediately catch on and he would decide to scrap it and start something new.

I finally jumped ship when it became clear he wasn't going to commit to a vision and his next idea was that we should make it a social platform.