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.
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.
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.
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.
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.
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.
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.
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.
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.
Odds are that you are enthusiastic to embark on your new career and you haven't been exposed to some parts of the real world yet.
Young developers are often smart, passionate, driven. They also fall for a million traps... reinventing the wheel, worrying about trivial things like syntax instead of the big picture, tripping over every new, soon to be discarded library/stack/tool.
Older developers are usually good at making things happen, but are often cautious, unimaginative, uninspired. They are good at delivering real world value though.
Just assume the cognitive dissonance you are experiencing is the result of having drive and education without enough real world experience to make sense of it all. You will do fine.
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.
My general experience is that a lot of the time you will get people who suck or just don't care as part of your group.
"half the groups don't know how to code (mostly webapps),"
To be fair, the point is to be learning how to do that. Maybe there's a problem with the curriculum in your school where these individuals haven't had any guided instruction.
"for my final summer I have an internship at Google."
I'm sort of guessing, but maybe you are also a well above the skill average for the class.
So in summary, likely a bit of both - some people who actually suck, and that Mayne you are on a different level.
It's very likely that everyone around you is simply measuring competency/success by a different rubric than you are. It's irrelevant what your college peers think, but the fact that everyone at your intership cared about different things than you do should tell you that what you think is important isn't in the real world.
And you know what? That's normal. Most recent graduates start their first job thinking that they know better than their older fuddy-duddy coworkers, and discover the hard way that most of what they learned in school doesn't apply in the real world. On the job, you will rarely have the time or resources to do things perfectly; the quality of the work doesn't matter if it gets the job done; it's a waste of time to solve for future problems instead of just dealing with the problems you need to address by the next deadline.
Chances are after you graduate, you'd regret spending too much effort on these projects and missing out other fun stuff in college, while the others offloaded their work to you so they could enjoy college life. Maybe you can think about what you want to achieve right now.
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).
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.
Which framework is selected shouldn't matter so much. If you expect others to use one you've picked and learn it, you should do the same with one you didn't pick rather than declare it's garbage and needs a rewrite. To your question: it's a false dichotomy.
Anyhow from the tone of your post I'd say it's both: yes you are probably ahead of some of your peers. At the same time however you have to accept that in life there will always be those less competent and motivated and you have to deal with it.
Sounds like this Amazon app you worked on just isn’t very important. I’m sure someone tried to get more resources to clean it up. But they couldn’t convince the higher ups of its business value. You could try to be a hero and rescue it. But, without a solid business case showing a causal link to business impact your efforts will go mostly unappreciated.
All 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.
Step one: be more resourceful, especially about major life decisions.
People are here complaining about Amazon culture being dangerous, or a joke, daily — you just needed to run the search.
However, as you have noticed, all of these things are far from the standard. No tests, code that barely works, devs that are barely able to code, etc. is the standard in many companies.
The people I know who are competent and motivated go down one of two paths:
- either work for a company that values and applies best practices - or work for a company that doesn't in a role such as an architect, where they have a lot of freedom in what they do, and spend most of their time finding simple ways to make poorly written applications work or writing POCs or starting new projects
To answer your questions:
> 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?
All of the standards you mention are best practices and are uncontroversial in the sense that they require little engineering effort compared to the benefits they bring.
Whether it's too much to expect or not depends of the context: if management or the more senior developers don't value it I'd say it's too much to expect.
However, if your colleagues aren't opposed to it or it's a school project I'd try to introduce improvements, starting with small things. For example, for the main branch that doesn't build you can explain why it's a problem (e.g. your colleagues will pull main before starting to develop something, and it's not nice to them to leave the project in a state where they have to fix things first), and introduce a solution (for ex. a CI job or a pre-commit hook that checks the project builds).
> Am I an arrogant or am I surrounded by incompetent people?
Some people value other things more than software development, don't mind repetitive work, are less driven, or even less intelligent and it's perfectly OK for them to be this way. So I'd say you're arrogant by judging them too harshly or expecting them to be different. However that's not the important part (though it's still a life lesson that I learnt much too late).
The most important part is that you should surround yourself with competent people so you can have more satisfaction in your work and learn new things.
- Your internships are what you make them. The names don't mean much at an intern level because Amazon and Google aren't going to hand you "exceptional software" as an intern. Learn as much as you can while given the opportunity.
- People are still learning, especially in school. Programming is hard for a large majority of programmers, even for the masters. You may be smart, but if you can't work with people, then you are not valuable. There is always something you can learn about yourself and your approach, even when surrounded by idiots. If you don't realize this now, you will waste time throwing away opportunities to learn and grow in CS and with your soft skills. Unless you start your own business or become a consultant, you will need to get used to working on a team, motivating them and teaching them to become better.
- There are two types of programmers, imo. One does it purely for money. The other is truly passionate about it. The ones who do it purely for money aren't motivated to learn and grow, so treat them as order-takers. They just don't care, but they're paid handsomely for it. Learn as much as you can from the ones who are passionate, because they never stop investing in tech. They will shoot you forward in your career and save you years.
- Everyone recommends tech stacks they're comfortable with. Tech stacks are not what determine the quality of work. What determines it is good planning, design, architecture, and refactoring. Readability is king. The best way to write software is to adhere to the nuances and quirks of the tech stack you're working with, and to have proper separation of concerns, which is an art that takes at least a decade of refinement unless you devour text books on the subject regularly.
If you allow me to be frank and you truly want to know what's going on, then let me tell you that the issue is that you need more humility. Objectively assess what is going on and do what is necessary to solve the issue (without "firing" your peers and complaining that they suck). Always be learning from the situation and take the most appropriate action to reach your goal (without being passive aggressive or hostile). Then hold yourself to the highest standard you can, knowing that people will rarely ever match your dedication to your work unless you're surrounded by passionate engineers. What matters is that you're always learning and growing. Anything else is a waste of your time and opportunity.
For example, when you see that there are compile time errors in the main branch, you need to get your team together and talk about why that is bad. People may genuinely just not understand why it is important nor care. Now being a principal engineer at my company, I have seen time and time again that people just don't know what they don't know because computer science is extremely complex and humanity has not figured out how to teach people everything they need to know. I've learned by reading a ton and trial and error, but as I said, people who just do it for the money will not find it out themselves. If you care about it, you'll have to establish yourself as a trustworthy leader, raise morale, get them to care, and then start teaching them. Not saying you're doing this, but if you sit around and complain that they're not as good as you or they don't understand what they should, you're not solving anything and you're just part of the problem. This situation will arise over and over in your career. If you understand there is an opportunity for you to grow as a mentor and leader, companies will flock to you and pay you handsomely for your skills, AND you will shape and mold your environment to your liking with higher quality and standards wherever you go.
Last thing to note...be PATIENT. Change takes time, trial and error, and refinement. Humans are stubborn and slow to change, especially in this industry, unless they're passionate about it and have humility to learn and grow and receive constructive criticism.
Hope that helps.
The main thing that is different about the AWS folks is they expect people to treat them like they are geniuses because they work at Amazon. Whatever solution they come up with becomes "the gold standard" because of who they work for, even if it doesn't work. The other thing that sets them apart is they can spin up free amazon accounts to test things - which is an incredibly massive advantage that they do not extend to contractors