Ask HN: Am I an arrogant or am I surrounded by incompetent people?
I go to a state school not really known for CS, although we have a huge CS undergraduate body. A lot of classes in CS require group work - which for the most part, I think is really helpful since most engineering in industry is done in teams.
I've had 3 classes where the majority of the grade is made up by projects, and many classes where we do many projects. In each class, I've had to carry the bulk (~90%?) of the workload - half the groups don't know how to code (mostly webapps), and the other half don't care to try.
I've tried many approaches - I find that if I recommend tech stacks that I'm comfortable with, most people won't care enough to learn them, but when I let others select, the project ends up as a steaming pile of garbage that doesn't work, and requires a rewrite the week before it's due.
School Groups that are lacking are not the exception, they're the rule - I haven't had a group be able to get anything that's runnable without almost taking over.
I thought that when I got to Amazon, things would be different: highly motivated people working on exceptional software. But the webapp I was working on (internal) was poorly held together, and the frontend had literally no tests and no way to get mock data locally - i.e. the engineers working on it were just guessing about the shapes of the DTO's, pushing to their personal deployment of the app, and then testing in the cloud before pushing to production. The feedback loop was brutal.
I really try my hardest to do the best with what I have - I've never lost my cool and always try to have a cheery attitude. But when I sat down and git pulled what our group had been working on, and there were compile time errors in the main branch, sometimes I wonder if I'm just holding my peers to standards that are too high? Is it too much to expect tests? Is it too much to expect to be able to test full stack locally?
I'm beginning to think that I just need a reality check on what standards to hold others to - but at the same time, I can't help but wonder how some of my peers are passing classes or getting hired.
EDIT: Thanks HN for all the helpful advice - I've read each comment many times and will probably come back to this post many, many times over the course of my career. Some of these comments have shifted my perspective on some things.
I can't reasonably reply to all comments thoughtfully, but they are all appreciated - thank you.
64 comments
[ 4.7 ms ] story [ 150 ms ] threadAll of that said, "are you surrounded by incompetent people?" Hmm... well... I don't know if I'd go so far as to say "incompetent", but let me put this suggestion out there (this is not a new idea, BTW). In years past, most of the people who were majoring in CS in college were people who intrinsically enjoyed computers, programming, electronics, etc. E.g., your traditional hardcore "geek" type. People like this programmed for the sheer joy of it, wore the title "hacker" proudly, and held themselves and others to a high standard of technical excellence. Today, on the other hand, a lot (no, I can't quantify this exactly) of people in CS are probably there because they heard that it's a field where you can make a lot of money, and/or because family and friends pushed them in that direction. They don't necessarily derive any intrinsic enjoyment from learning newer and better techniques, learning new technologies, or trying to "one up" their colleagues with technical excellence.
Is this true? Hard for me to say, as University was ~25 years ago for me. I only saw it the way I experienced it. But based on what I see in industry, and what I hear from others who are still in school, or who entered industry at different times, I tend to believe there is something to it.
but at the same time, I can't help but wonder how some of my peers are passing classes or getting hired.
That's one of life's great mysteries. You may have heard anecdotes like "I interviewed a guy with a documented Ph.D. in Computer Science and he couldn't code fizz-buzz" and thought to yourself "there's no way that story is true." I'm here to tell you, I've been the guy delivering that anecdote and it's absolutely true. Perhaps even more to the point, I've interviewed people who had documented 10+ years of industry experience as developers - apparently having some modicum of success along the way (they didn't get fired after all), but yet still couldn't write fizz-buzz. Which is all a long winded way of saying "What it takes to have some modest level of success as a software developer in industry may not be what some of us think". And apparently fizz-buzz isn't all that great a predictor of whether or not someone can somehow, someway, find a way to deliver code when needed. Take that for what it's worth.
To add, also take into account that there were almost no state school CS programs until not that long ago. Many of the graybeards I learned from along the way had English and Music degrees, they autodidact-ed the rest through trial/error and collaboration with peers (and official systems manuals).
These are the cats that ran anything from VAXen to high-end CAD workstations and whatnot, wrote internal mission-critical applications with no formal CS background. Just passion.
Take also, the generation of COBOL jockeys whipping up reports and maintaining ancient stuff (also mission-critical) who learned on the job and were never taught algorithms and beyond.
Even at the AMZN gig mentioned by OP, whatever he was working on was a cost-center. If a team at that level can create its own stack, guidelines and the like, mistakes will be made.
Fixing that requires investment, and I can't imagine that any resources were invested in that app, because cost-center.
This hits the nail on the head.
How do I cope? I'm very particular about the team I work with. You can't choose everyone you work with of course, but to some extent, you can.
I've interviewed at FAANGs where the interviewers were clearly dead inside and don't give a damn about what they build, and are either coasting or optimizing for promotions/resume.
I look passion in my prospective colleagues attitude towards work, which I find to be a good predictor for whether I'll enjoy the environment. My anecdata suggests this also works towards better product success on average.
In the business world, the time of highly motivated, talented engineers is extremely valuable. It doesn't make sense to dedicate any more of their time than necessary for the average internal webapp. Adding automated builds/tests is usually time that's not being spent on more impactful initiatives for the business.
Do I like this state of affairs? Not at all. But it would be silly to ignore the plain, obvious truth.
My previous philosophy was that few projects past MVP stage are deploy and done, and it's a major long run time sink to have to deal with the problems not having the basic tooling creates.
I like to think about it like this: A project looks like y = mx + b, where b is the overhead of inital setup, y is the output, x is dev time and m is the efficiency of devtime. If you skip the setup, you lower the b to 0, but with enough required y you actually end up paying more cost (and time = money since someone is cutting devs a check) than a project with more efficient dev time (lower m).
I had thought that in general testing + automation is worth it in the long run. Thanks for your input, perhaps my previously held philosophy is based on the flawed idea that all projects have some degree of maintenance required.
Doing all of the best practices can mean your competitors beat you, just because they deliver "good enough" faster than you deliver perfection
It's not ideal but it's reality.
A lot of people are in CS/SWE these days because it's what pays, or because they find technology interesting (i.e. "geek culture").
If you are in the field because you are passionate about the field itself, and/or have an aptitude for it, that puts you in the minority. But your skills will reflect your passion, hence, your experience with differential skill levels thus far.
I've been fortunate to land a few gigs with talented and passionate individuals (one recent gig I worked in the same room as two OSS figures whose work you likely have used).
But even then, I've met maybe only one or two individuals (both lead developers) whose multithreaded code didn't have obvious (to me) bugs in it. Even talented devs aren't passionate about stuff like that, and thus just don't learn it very deeply before applying it.
Just remember to be patient and humble, people will look to you as a leader.
I'll happily tack a book on the reading list, but he's written much more than one book!
Your teams will get better than in college, but the software..
When you accept it, you can start to focus on controlling the trash fires in tactical ways - it's a big part of the job.
If you take to time to make software to your standards, all the companies with lower standards will crush you.
> I go to a state school not really known for CS, although we have a huge CS undergraduate body.
This is a big part of it. If CS isn't a strength at your university, why would you expect your classmates to be highly interested/capable on average? Lots of people are in the field purely for the money. Hell, lots of people are in the field thinking they'll hire a team of engineers to implement some master plan and IPO their way to riches.
> I thought that when I got to Amazon, things would be different: highly motivated people working on exceptional software. But the webapp I was working on (internal) was poorly held together...
Back to my original point, you were an intern. You certainly were not working on critical systems at aws. Things will get different real fast once you're working somewhere long-term on systems directly affecting the bottom line. With so little experience, its a bit early to assess the industry as a whole.
Learn as much as you can. If you keep pushing, you'll end up where you belong. If you decide to mail it in and collect a paycheck, you'll be stuck with other people who are also mailing it in.
You just need to find a way to make the best of your situation. Usually this means stepping up, providing technical leadership, taking on the most complex tasks directly, and finding simpler tasks that others can take on. And finding ways to do all this without alienating your teammates.
> But the webapp I was working on (internal) was poorly held together, and the frontend had literally no tests and no way to get mock data locally - i.e. the engineers working on it were just guessing about the shapes of the DTO's, pushing to their personal deployment of the app, and then testing in the cloud before pushing to production. The feedback loop was brutal.
It's hard to provide feedback without knowing more details. For a prototype or MVP or low priority project, the right thing to do sometimes is to avoid all overhead and take on a lot of tech debt. The real question is whether these shortcuts are actually increasing velocity or reducing it. If it's hurting velocity but people don't care to fix it anyway, that's a sign that you should look elsewhere.
IME, teams that build internal tooling tend not to have the highest engineering quality within the company. Something to keep in mind when choosing which teams to join.
Furthermore a prototype or MVP may not be intended to have along life from the start. It likely is just to test a theory/concept/business model. Then if there is traction, it will be rebuilt more robustly.
In this case, Incur as much debt as needed to fail fast.
You are not alone. Unfortunately, you will find the your experience is generally common in the industry. Care for the craft is something rare. On the upside side you will excel in engineering work as an individual contributor if you can develop a good attitude. On the downside you will spend many years dealing with people whose competency is questionable at best.
As for what standard to hold others to: be patient and kind. Always assume good intent. Enlighten others in any way you can and be gentle while doing so. Raise the bar for them one millimeter at a time if neccesary. It takes time and effort to earn trust, but once you have it you have the capability to uplift those around you, which is a precious gift. Don't squander it because of pride.
My advice: be proud of your high standards but don't look at others to be like you. I was kinda like you in my 1st job and realized quickly that you cannot control what other people do. You can only do what you can do. So do your best and be proud of it. If some things are not getting done, it is not end of the world. Don't look for perfection. No one cares if you wrote that additional test (well in grand scheme of things). People will remember you based on you getting stuff done and being able to work with people who could trust you to get things done and bonus if they really liked working with you.
So, be nice, get along with people you work with, provide inputs but if it doesn't go too far, don't get disheartened. Make sure you are making a difference on your end, no matter how small and ONLY judge yourself. Good luck.
> ONLY judge yourself
This is great and very useful advice.
This advice will only work in the beginig. There will be the point in career where he needs to judge other abilities and involvement to properly allocate work and manage projekt successfully.
A lesson you don't learn in school, and is even hard to learn in professional life, is that engineering is about getting the best work done inside the constraints you're presented with. Sometimes its time constraints, money/resource constraints, business constraints, political constraints, environmental constraints, etc..
You'll never be given a perfectly well thought out spec/design/etc and infinite time and resources to build the absolute best solution. You'll have to compromise on things when you're doing real work. And sometimes people will disagree with the compromises you had to make, like you are with this team at AMZN.
At the same time it's okay to move on to different teams and different companies looking for a really exceptional situation where everything goes great all the time. But realize most of your career will not be under those conditions. And that's okay, you can still learn and grow, and get paid to do it, even if there are problems.
Then I ended up being in charge of new engineers. I would shoot down their ideas, and essentially force them to do it my way. Eventually I realized that I was hampering their growth for stuff that didn't matter as much as I was thinking, so I relaxed a lot in how I approached things.
My guess is that a lot of what you consider important isn't really that important -- particularly at Amazon, where your co-workers probably have a better idea of where the priorities are. Also keep in mind that even the best of software tends to accumulate technical debt and fixing that rarely bubbles up to a high priority. Which isn't to say you shouldn't push to fix issues you see (indeed, that is often why interns are hired -- to take care of the stuff that regular staff doesn't have time for), just that you shouldn't automatically assume you know more.
I think large companies, including FAANG, have more parts of the org where slacking off is tolerated (not suggesting your coworkers are but there can be a sense of "how does this help anything?" at larger companies). I would suggest seeing if you can intern at a startup or smaller scale company if possible. It will help give you some comparisons to your other internships.
Internal tools are usually guilty of shoddy/lazy work because, well they are internal. Nobody sands the 2x4s that make up the insides of a house's walls. The companies money spent on engineers is usually spent better elsewhere. This is a key for job hunting in the software world - you want to be working on a product (brings in profit) vs. being in a cost center. You'll be treated better, paid better and probably be around people that are also more passionate about the work.
I went to a state school for CS where it was a new department having been under math a few years before. This was before google existed, or maybe it was in a garage at that point. Money didn't occur to me, I just liked computers, was always tinkering to get games working and picked CS. I've seen a fair number of people pursue CS/software because of the money. With that being the motivating factor, they don't last long or they progress into careers tangential to programming like PM, business analyst, etc. and are successful.
What you're seeing is just a part of life in the working world. Keep in mind that people may have things going on outside of work that consume a lot of their energy (kids, divorce, deaths in family, etc.) and it will affect their work.
That being said, as many people have pointed out, understanding why compromises were made in certain cases is important. Sometimes compromising on things like code quality is actually the right thing to do for the business. More often than not it isn't and this get's thrown out as an excuse for low standards.
Go see more types of environments. As a consultant who has got to work on probably approaching 50 teams in my career, I'd say maybe 10 or less were decently functioning and 5 or less were truly well run. Which means you may need to look through a lot of places to find a group of people who are able to manage themselves and maintain high standards. It's worth the search though.
note: never worked in FAANGMETC. I've never seen high coding standards in non faang enterprise (banks and hospitals).
For Amazon, I dunno, maybe your expectations are too high. I have a bachelors in Computer Engineering, and took a couple courses in formal/academic Software Engineering. From my 20 year career in software at internet companies, I don't think anywhere I worked was even trying to be beyond CMMI Level 1. It's just not something anybody cared about; including me. You can't use formal methods without a comprehensive specification, and nobody is going to write a specification at all, let alone a comprehensive one, so there you go. If you work in aerospace or automotive, it would probably be significantly different.
My experience with tests were that they were useful only for parts of the project that didn't change, but most of the project was subject to change; so tests were mostly wasted effort (twice: once when you write the test, and another time when you have to throw the test away because the requirements changed). Full stack local testing is nice, but it's not free and if it's easy to test "in the cloud" or in production, then that's what you're going to do. I would focus on reducing the cost of deployment so that it's easy to push small things to production, so you can test in the real environment and rapidly iterate; but again, I'm not working on anything close to life safety.
As you gain experience, you want to be figuring out what kind of environment you want to work in, so that when you interview, you can figure out if the position you're interviewing will provide that environment. Having an internship somewhere where you didn't like the environment is great; it gives you a real anchor point to ask questions from. Of course, you have to work somewhere, so you can't be too picky, but you can at least be mentally prepared.