9 ms·

Ask HN: Am I an arrogant or am I surrounded by incompetent people?

57 points by AmIAnElitist 4y ago

I've generally stuck to the mantra in life that "If it smells like shit everywhere you walk, check your shoes". I'm currently a Junior in college - I've had an internship at Amazon last summer and now, for my final summer I have an internship at Google. 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.

mindcrime 4y ago
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.
- jprd 4y ago

mi100hael 4y ago

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.

mindcrime 4y ago
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.
- nuancebydefault 4y ago
  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' .
AmIAnElitist 4y ago
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.
- noodle 4y ago
  Many business, products, features, etc never survive long enough to get to "the long run".
  - bluefirebrand 4y ago
    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.
    - noodle 4y ago
      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.

toast0 4y ago

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.

kren 4y ago

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.

AmIAnElitist 4y ago
> 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.
- kren 4y ago
  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.

n_e 4y ago

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.