That's an incredibly privileged point of view. It is not frequently the case that students with the apitutude for college have the support they need from family and relevant experts at school to engage in the kind of thoughtful deliberation you suggest.
It does take more support from family and counselors, because it's swimming against the current. It's easy to jump right into college when everyone's drilled it into your head that you need to go, regardless of your particular personality/goals/stage in life.
That effect to not go against the grain should be more extreme in communities where 99.9% of students attend college.
Regardless, the issue isn't to pick your path exactly before you go. The point is to be prepared to dedicate some marginal effort to it either at the beginning or before.
You really think it's on the schools to tell students what they should learn or what degree they should get? Certainly people have different amounts of support going into it, but we can't just keep pushing the age of personal responsibility further and further out. To absolve underprivileged young adults of these key steps in life is not only harmful to their personal development, but I'd argue personally insulting to their potential as independent adults.
> You really think it's on the schools to tell students what they should learn or what degree they should get?
No, not me. I agree with you that we've pushed the age of adulthood too far out.
But when the mistake you learn from comes with crippling debt, it is on us to guide kids to make low-consequence mistakes before the big ones. That's why I suggest we encourage more real-world exposure with internships, co-op programs, shitty jobs first. We need to foster the environment that allows kids to actually critically think about their future instead of shoving them towards it, and we need to practice the meritocracy we preach by looking past degrees to hire people.
It depends on the school -- Some schools have a broader general education focus, with less major-focused work, and enough of an opportunity to explore before declaring a major.
Others require you to pretty much declare from day one, and it might well be another $50,000 if you get it wrong.
No, you can't pick it up "very, very quickly." That is a dismissive and indirect way to assert that engineering is somehow easier or requires less intellectual rigor than "higher" disciplines like CS or math.
I tried to make it very clear that you can pick up the knowledge-based part - or that part that you can learn at school or using books, which is also the part that is tested in exams - quickly. In that respect it is indeed easier.
What may not be that easy is the experience to make good decisions. But there is no clear path for that, except being an engineer for a sufficiently long time. This piece was targeted at students and you can't just tell them: "Keep working somewhere else for 10 years".
The first sentence in the article encapsulates one of the biggest problems in this industry. It may apply to very specific roles within certain companies, or to specific subdisciplines, but in general the statement is little more than an unsupported assertion. It is very popular in a population heavily weighted by CS graduates, but popularity doesn't imply correctness.
As a thesis statement it is wildly out of sync with all but a few of the bullet items, most of which have almost no relation to "CS fundamentals". Working on projects outside of class/work is broadly applicable to any field, as is contributing to large projects as part of a team or group; neither of these requires "CS fundamentals." OO programming and learning specific languages are likewise disconnected. Some of the points aren't bad with respect to being required in order to be a good software engineer, but even those are too scant on detail (even for a bullet list).
Most of the "learn about" points are vague. In particular, as an example, the point about DS/algorithms is awful. What does "learn about" mean? Satellite engineers "learn about" materials, orbital mechanics, radiation and E&M, but they aren't in general expected to know the fundamentals (as a physicist would understand the term) of the theories of particle physics or gravitation for example.
The bullet points read like a survey of random computing related topics. There is no focus or cohesion connecting them to being a good software engineer. It reads like somebody's random meanderings when contemplating something they might find interesting within the field of computing. It's not a guide; it's a disconnected hodgepodge.
Remove everything that isn't related to being a good engineer (that would be almost all the points about sub-discipline-specific items, like machine learning), elaborate on the DS/Algorithms points, and provide something in the guide to actually support the opening statement (good luck).
I generally agree, but I would also argue that they've left off the things that relate to being a good engineer, at least for engineer in the traditional sense.
One thing I learned in the briefings I saw after getting my clearance was that the single biggest motivator for betrayal was a thrill-seeking narcissistic personality, followed closely by political agendas. Financial (including bribery/blackmail) and romantic blackmail concerns were so tenuously correlated as to be laughable to suggest they are meaningful as a potential exploitation.
You haven't established the link between wealth and an understanding of productivity so much as asserted that wealth is a proxy for knowledge/intelligence.
One plausible reason: the story is a "slow burn" story that hasn't had time to gain traction. Mainstream news acts more like an aggregator of information that percolates out of various niche segments' echo chambers: give it time.
Another thing to consider: what is particularly newsworthy about it to the general public? Software technology focused people would find this very news worthy. I have little sympathy for a business of any size that uses github as its primary repository: the most-current source should be maintained on an internal server, in my opinion, and companies that require github to be fully available to operate are doing it wrong. I mean one of the primary advantages of a distributed repo is that there is a complete history for every node that has synced with the most recent commit. There shouldn't be a strong dependence on a central repo.
> There shouldn't be a strong dependence on a central repo.
Most groups are not setup like the Linux kernel where there is a "gatekeeper" who is a person that directly pulls from other people's repos (or from commits sent to an email list).
A central repository becomes "the truth" and once something is "the truth" it becomes the person that wants to push their code to this repo to do the merging. There is nothing about this that is inherent to Github in particular, but telling everyone to change their "origin" remote to point somewhere else can be an issue depending on how large your group is. And what if someone manages to get a push to (e.g.) master through the Github DDoS before everyone is on the new remote repo? Now Github and BackupRemote have branched, when you really want BackupRemote to be a superset of the copy on Github.
There is not one single other engineering profession I'm aware of that thinks a "portfolio" consisting of past employment is insufficient, or that has academic trivia questions figure as largely in their interview process.
To me a request for portfolio contents beyond the contents of a resume is an indicator that the would-be employer is interested in people who are easily exploited or cajoled into working lots of unpaid overtime, or else that they don't actually trust the candidate's resume; both of these are negative indicators. A heavy focus on DS/algorithms for engineering positions is an indicator that the employer either doesn't understand the difference between academics/theory and engineering or, worse, thinks the latter is trivial, irrelevant, or otherwise beneath CS; both also negative indicators.
what you are saying is relatively true for developers with some experience, especially engineers. This is not true for people coming out of online learning programs who know the basics of coding but haven't built anything significant. For these people, the resume is empty so building a portfolio of significant projects is a way to become a developer. It is as much self-serving as it is serving the needs of employers.
That's true, and it is a case that seems to be unique to the software field as far as engineering is concerned. I'm also unaware of any other engineering profession in which such shallow education and experience would be considered acceptable in any case. Usually a four-year degree from an accredited engineering school is a minimum requirement for even entry-level work. In these cases references and some casual "technical" discussions (but nothing like the pedantic Algo/DS grilling in a software interview) in the interviews will determine suitability, and the individual will effectively be considered a trainee for a time. That is also absent in the software industry, generally.
"Self made" defies precise definition. If you start with $999,999 and earn $1 by your own efforts, a strictly precise definition for "self made" would imply you were a "self made" millionaire. However it would also apply to somebody who started with $1 and earned $999,999 by his own efforts. Hence using "self made" in both cases renders the phrase so broad as to be empty of meaning.
It doesn't need a precise definition. I think most people will understand what you mean when calling someone a self-made millionaire. That's all that matters: the phrase conveys a meaning.
I'm sure it has a meaning, just probably not one you'd agree with?
I've had this debate with others before, and "self-made" overall tends to mean that an individual did something in isolation. I.e. It plays into the narrative that "no man is an island" and that we all owe our gratitude to the society we were part of, as if the society had some direct doing in it.
I find that to be not true. Most engineers suck at regurgitating the correct textbook CS algorithm or data structure from memory, but they are very good at engineering, which is what the overwhelming majority of programming is.
If I had to choose between a CS major and a ME for an engineering project that involved software development I'd choose the ME almost every time, all else being equal. The exceptions would be cases where academic CS knowledge is required. They exist but not nearly as frequently as Silicon Valley would have anybody believe.
No he's saying most mechanical engineers can't program and most CS majors can't understand the mechanical engineering math. The OP is perfectly positioned to bridge the gap between the two.
This is a great comment. The category error you've identified is manifest in more than the comment you're replying to as well: it's at the heart of one of the biggest problems with software interviews in a certain sector of this industry (the heavy focus on academic CS in startups and many Bay Area tech companies).
