Ask HN: Am I an arrogant or am I surrounded by incompetent people?
64 comments
Welcome to getting a taste of the Real World. I cannot comment on the "incompetency" question but I would give you some general advice (18+ years in the tech industry). In the real world, there are trade-offs to be made. Sometimes it means that you won't have enough time/resources/incentive/priority to do automated tests. That is not always a bad thing. Focus is usually on getting shit done and yes that sometimes means not perfectly.
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.
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.
Thank you for the advice. I generally try to silence the cynic in me, thank you for reinforcing that.
> ONLY judge yourself
This is great and very useful advice.
> ONLY judge yourself
This is great and very useful advice.
>> ONLY judge yourself
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.
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.
WRT your experience at Amazon -
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.
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.
Your experience at Amazon probably isn't due to the incompetence of others, but due to a difference in alignment.
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.
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.
It's a shame that you're being downvoted, because there is a lot of merit to what you say. Business leaders do not always value technical craftsmanship and quality to the same extent that we do. And that creates situations where even competent developers are incentivized to cut corners, deliver work that they aren't necessarily proud of, etc. But as long as "the business" is funding the work, and it is "just good enough" to meet their needs, that's the way things are going to remain.
Do I like this state of affairs? Not at all. But it would be silly to ignore the plain, obvious truth.
Do I like this state of affairs? Not at all. But it would be silly to ignore the plain, obvious truth.
Indeed. The business people often think cutting corners is not a big deal, especially to win time, while technical people who are in till their elbows simply know it is not the best strategy. But the latter should think, 'it pays the rent' .
I'll take this viewpoint into consideration, thank you.
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.
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.
Many business, products, features, etc never survive long enough to get to "the long run".
Also, many businesses, products, features, etc never survive long enough to get to "the long run" specifically because people were building out automation, testing, etc.
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.
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.
Yep, for sure. I've witnessed this first-hand, too, many times. Watched many startups die from this desire to build the perfect version of a thing that no one wants to buy.
Part of growing as a software engineer is knowing when things really matter and when things don't. When I first started out, in my mind there was a "right" way to do things (my way of course) and a wrong way. Sure, the wrong way could work, but it was ugly and bad code (in my mind). I would fight constantly to ensure things were done the "right" way.
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.
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.
As Tom West wrote: not everything worth doing is worth doing well.”. As a student or intern, I would imagine you’re far from the bits that are mission critical. That leaves makework, or kept around as it’s somewhat useful, or some other “ehh” descriptor. And I suggest living will be better if you assume people know more than you do rather than less. Avoids running afoul of the quiet smarties.
If you're a Google caliber engineer, you're going to be significantly better (at coding) than your average classmate at a "state school not really known for CS". There's nothing arrogant or elitist about this - it is just statistics. Which is not to say that there's anything wrong with your classmates. If I put you in a class together with the likes of Jeff Dean, the roles would be reversed.
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 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.
Good point about tech debt.
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.
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.
> 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.
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.
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.
I think life is too short to waste it maintaining automated tests on an internal frontend.
Every software project is a trash fire. Incompetence can definitely make a more severe trash fire, but the vast majority of the time, it'll just be due to constrained resources. There's never enough time to get anything truly "right."
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.
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 have had a similar experience. My current strategy is to find a place where I am the least useful person in the room, over time my competency will expand until I stop being challenged. Once that happens move on to another place where I am the dumbest in the room again. If you are currently bored/unchallenged I would say to implement some automated testing, then go to your manager with your honest feedback. They might find a better fit for you or give you more responsibilities.
It's probably somewhere in the middle. Frankly, your stakes haven't been very high. I promise you'll notice a difference once you're doing work where money is on the line.
> 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.
> 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.
My (somewhat cynical) observation from 10 years in the industry (and 30 years total of coding):
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.
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.
Others have said bits, and I’m repeating it for emphasis: don’t look at labels, don’t look at school name(s), don’t look at titles…. Look at the code. Can they design, can they code, can they debug, can they work on code they didn’t write, would you bet your ass on their skills? These are the valuable people to find and know. Be like them and you’ll never go hungry.
Most college students in Tech are trash. If you care and have aptitude you'll be in the vanishing minority. The workplace? Much the same, but it varies so much, but it's often the same. I'd say, just keep looking, you can find a job where people aren't trash, but you might have to look.
You might be a bit arrogant, or driven, or passionate. You are surrounded by people that might be lazy, less intelligent, or less capable.
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.
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 school groups, you really want to find competent people and register for the same sections of team project classes as them, so that you can work with them. (This might be considered networking). My school's student body was pretty small, so I had a good read on people after one year, but you should have some idea after three.
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.
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.
"A lot of classes in CS require group work"
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.
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.
I used to know someone like you, who thought they were the best programmer out of anyone they had ever met. They used to brag about how good a programmer they were, how they "aced" every tech interview they ever had, how everyone else at work was so incompetent and they were the only one who knew what the company should be doing. But it turns out that all of this superiority was just in their head. Everyone else thought this guy was just barely competent, and he kept getting fired from jobs because he insisted he knew more than everyone else and could not accept that he did not.
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.
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.
A lot of people would freeride because someone else would do it. They aren't really incompetent. They just value something else more than school projects. The "sad" truth is that they'd probably do just as well, if not better than you, after graduation.
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.
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.
Intelligence is the ability to consistently get what you want out of life. This definition really helped me expand my understanding of intelligence and helped me see intelligence in other people that I had previously dismissed. If people are failing to achieve their goals, then you can credibly conclude they are incompetent. If they are still able to meet the goals they set even though they are not doing things the way you think they should be done, then you should revise your evaluation of their intelligence
I would say consistently achieving your goals is effectiveness. Intelligence can help you be effective, but it's neither necessary nor sufficient.
I think what you're experiencing in group projects at school is similar to the work world, probably more amplified because any school project has a lot lower risk than at a job where one could get fired.
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.
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.
I don't think you're arrogant. You will find low standards many places you go in the world and seeing an opportunity for something better isn't inherently arrogant.
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).
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).
In fact, I think most technical people go through this process at their first job(s). Thinking that in the real world, in a professional context, work is done in a way that is considered professional ie. using best practices, high quality standards and so on. And then realizing that it is not always or even often not the case.
However, after switching jobs quite a few times the last 5 years, I found the level of professionalism varies a lot between companies, and even between teams of the same company. So it could be that changing teams or jobs would be beneficial in your case. But you need to try to keep in mind that coworkers in general have good intent, even when at first sight that does not seem to be true. There are many ways to provide a solution to a problem, hence different orders of priorities (time, quality, features, testing, lines of code, level of optimization and so on)
I don't think you are arrogant but you sound very rigid and simplistic in your view of work and life. Strive to do better and strive to help those around you do better. You don't need to have fixed standards and then freak out when people don't meet those standards.
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.
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.
> 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.
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.
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.
That's the norm in school for sure. Many kids take a degree for the perceived value on paper but are never truly into the subject, don't try much, etc... At Amazon are you with other interns or what? Or maybe your sense of perfectionism is getting in the way of you simply getting things done...
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.
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.
You should not lower your standards, rather adjust them to the context. Know when high standards are appropriate and when you should lower your standards.
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.
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.
Well... there does tend to be a certain measure of arrogance that comes with youth, and if you're still at University, then you probably do have a touch of that. But that's normal and nothing to feel bad about. It takes some time (the amount depends on the individual) for that arrogant sheen to wear down a bit, and to be replaced by some combination of apathy, cynicism, acceptance, etc.
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.
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.
Great points!
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.
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.
> Today, on the other hand, a lot ... of people in CS are probably there because they heard that it's a field where you can make a lot of money... They don't necessarily derive any intrinsic enjoyment from ... technical excellence.
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.
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.
You just haven't met the right people yet. I've felt the way you do in my CS journey several times, but I have also worked at places where I have been the least knowledgable person. The thing to know is that even within the industry, the range of skills vary wildly. Just don't fall into the trap of becoming arrogant. Be patient and helpful, and you will do well.
[deleted]
Okay. So you'll need to lower your standards. I went to an engineering school with tons of group projects. A teammate that did little to nothing was not unusual. If anything, it prepared me for the workforce. The 80/20 rule applies: 20% of the people do most of the work.
The world would make more sense if you read the small book that C. Cipolla
wrote long ago. See https://en.wikipedia.org/wiki/Carlo_M._Cipolla
Which book in particular? Are you talking about "The Basic Laws of Human Stupidity" ?
I'll happily tack a book on the reading list, but he's written much more than one book!
I'll happily tack a book on the reading list, but he's written much more than one book!
Change jobs until you find people that are a good match for you. That’s what I did. It works.
> I thought that when I got to Amazon, things would be different
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.
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.
I knew what I was getting into - It'd be silly to blindly accept an offer. My general cost-benefit analysis was that if it turned out to be a horrible experience, at the very least I'd have Amazon on the resume. It actually turned out to be a great experience, despite the issues I mentioned.
Also, behemoth companies like Amazon cannot possibly be generalized.
Also, behemoth companies like Amazon cannot possibly be generalized.
Sure they can: "there's a nonzero chance of [behavior you've heard of somewhere in the behemoth] happening to me if I work here".
[deleted]
In the ecosystem I work in, it's normal to have automated tests, it's normal to have a main branch that builds, and it's normal to be able to develop a full feature locally. Plenty of other things that make coding and deployment easier, faster and more reliable, such as using containers, CI/CD, or error reporting are normal too.
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.
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.
You're just starting your path on computer science, and it's common to feel this way when you're approaching a mid-level engineer. But do realize that the entire industry is at its infancy compared to many others. Here are some things to think about:
- 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.
- 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.
> then let me tell you that the issue is that you need more humility.
Perhaps this is exactly the criticism I need to hear.
> 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.
One slightly tangential thought that this lead me to was that currently, I get a new team multiple times a semester. There simply isn't time for this overhead every single time. Teaching takes time, gaining trust takes time - this might be one of the causal factor for the poor quality.
I try hard to not be part of the problem, but you're right that there's always more that I can do and every moment can be a learning experience - I can think about a couple times I had the potential to be a much more positive impact.
Thanks for the advice, I really appreciate it.
Perhaps this is exactly the criticism I need to hear.
> 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.
One slightly tangential thought that this lead me to was that currently, I get a new team multiple times a semester. There simply isn't time for this overhead every single time. Teaching takes time, gaining trust takes time - this might be one of the causal factor for the poor quality.
I try hard to not be part of the problem, but you're right that there's always more that I can do and every moment can be a learning experience - I can think about a couple times I had the potential to be a much more positive impact.
Thanks for the advice, I really appreciate it.
Absolutely. School does not accurately reflect the real world, but it's still important to keep learning. The moment you measure your progress by seeing you're better than others is the moment you throw away every opportunity to learn and grow.
I had a similar situation in school where I had a new project and team per quarter. One friend on one team didn't do anything, and the team tried to fail him because we put in all the work. He cried to his teacher and got a pass anyway. The real world can be like this too, actually. I find that managers are usually not willing to fire bad employees.
But anyway, it could be true that there simply isn't time, but I encourage you to try anyway because you will gain experience, even when you fail. The moment you conclude there is no time is the moment you stop learning and growing.
Of course, do what you care about and don't burn yourself out. In the end, you always return to asking yourself if what you're doing is working toward accomplishing your goals.
Thanks so much for reading my post and best of luck.
I had a similar situation in school where I had a new project and team per quarter. One friend on one team didn't do anything, and the team tried to fail him because we put in all the work. He cried to his teacher and got a pass anyway. The real world can be like this too, actually. I find that managers are usually not willing to fire bad employees.
But anyway, it could be true that there simply isn't time, but I encourage you to try anyway because you will gain experience, even when you fail. The moment you conclude there is no time is the moment you stop learning and growing.
Of course, do what you care about and don't burn yourself out. In the end, you always return to asking yourself if what you're doing is working toward accomplishing your goals.
Thanks so much for reading my post and best of luck.
Consider both to be true as these are not mutually exclusive.
I work with a lot of Amazon AWS engineers as part of my job.
I find that they are no better than any regular non AWS employee with some AWS experience. In many cases the Amazon employees are actually pretty new and have a lot less experience than the contractors they are working with - but their egos are massive.
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
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
there's always the possibility that you're the world's best software engineer. this is what the view would look like for that person.
What are you interested in doing after graduation?
Stop letting others take advantage of you.
Yes.
Do you get paid more to care like this?
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.