Hacker News Reader

Comment by vanusa | Hacker News Reader

I've been at it intensively for a couple months and my mind simply refuses to cooperate. If anything, after having done 400+ problems I seem to be worse at them than when I started.

Yup -- brain fog, paralysis and negative performance are the sure-fire signs of burnout (as least as pertains to your capacity for grinding LC). Excellent preparation for the daily grind of actually working for companies that rely on these tests.

Leetcode isn't about fun and challenging things, it's about thinking in one particular way, spitting out solutions using the same exact data structures and jumping through hoops on command without philosophizing or creating anything that can be reused/extended.

Exactly. And these are apparently precisely the "skills" these companies are "desperately" seeking to find among the engineers they invite for an on-site interview.

And don't forget the strong "culture fit" signal indicated by the sheer willingness to grind, grind, grind.

You memorize, regurgitate and participate in the agile masquerade. Creativity is shunned. Tried architectures/patterns are what is expected.

That's ticket. This is exactly the mindset these companies are after. That's why they swear up and down on the efficacy of these tests.

On the bright side: at least you've been freed of any illusions, by this point, about the intrinsic value of your advanced hard science degree.

View on HN

This leetcode (and similar) nonsense is really ruining our industry.

I've been delivering commercial products (that's the goal, no?) for over twenty years, regularly get high praise and top ranks in reviews, get promoted often including to "distinguished" and "chief" levels (always as a technical IC, not in management).

Yet.. no way I'd ever pass any of these leetcode style memorization interviews. I guess companies think that proves I can't develop? Funny. But sad. Our industry should not be like this.

Personally I feel lucky that this leetcode interview disease started after I was fairly senior already, so I'm getting hired based on track record and connections who love to hire me to deliver products. Hopefully, fingers crossed, that'll carry me to retirement.

But if I was in my 20s or early 30s, I'd be looking to leave tech entirely and go into something else where experience is actually appreciated and valued. None of my high school friends who went into medicine, law, finance, etc have this type of problem in their industries.

I've been delivering commercial products (that's the goal, no?)

No.

Once a company grows to a sufficient size the goal stops being delivering products and starts being not ^&*£ing up the product that generates a lot of money. The aim is to hire people who won't get things wrong, either by making errors or by introducing new unproven ideas.

"Deliver commercial products" includes the part of continuing to deliver those products over many years and many releases, without any regressions. It's part of the job.

OK, but it's a different set of skills. Leetcode challenges optimize for finding devs that believe there's One True Way to do things, and that creatively deviating or using a mathematically non-optimal solution for reasons outside of the code itself is Bad and Wrong. If you want to continue delivering a successful product without breaking things those are good things to look for.

They're the same skill. The difference becomes implementation. When delivering consistently what you're also doing is critically examining when or if the trade off value exists.

Sometimes the best answer is the one that maintains an API that was introduced in a beta that one customer is using. Sometimes the best answer involves breaking a 15 year old API that the entire country's electrical grid requires. But in both cases we're always looking for a single answer, a One Ring to Rule them All. The end-point or approach-point trade off considerations are IMHO, the real issue.

If you don't want to break things you simply don't alter the state of being. If you want a successful product over time it requires innovation. These goals are at odds with each other.

We’re generally talking about large complex distributed systems with tons of throughput.

As LC itself demonstrates, there typically are multiple ways to solve a problem. Most engineers will do the brute force approach and stop there because it does in fact solve the problem. And for most companies that will be enough.

The issue here is those types of solutions can be catastrophic for these larger tech companies… some algo that’s part of a tiny feature cab cause a massive performance regression.

When it comes to these algos, computer science dictates there is an optimal time and space complexity solution. There are also more clear and more obtuse ways to achieve what is technically an optimal solution from a performance perspective… often these can be found and discussed in the LC discussion sections. The more obtuse… ie trying to get to a minimal LOC, might be fun from a competitive programming perspective, but terrible for production code that needs to be maintained by coworkers.

So there is a craftsmanship aspect to it that goes above and beyond these algos, but ultimately there are optimal time and space complexity approaches that need to be adhered to.

Now no one is perfect. You’re not always going to come to an optimally performing solution. But if you’re good enough at this stuff, and your coworkers are good enough, it’s going to be rare that a PR enters the system that causes some notable bottleneck. And when it does, you should have the mental toolkit to quickly determine what happened.

Making a call to arms avoid this stuff as it stifles creativity is sorta like the folks who say learning music theory can harm someone’s ability to compose music. If you’re a pop songwriter, perhaps. But what if you need to compose a symphony? You’re just not going to luck into it with a basic understanding of music theory and advanced composition.

It’s just one kind of mental toolkit, and somewhat orthogonal to knowing the apis and design patterns of some framework you’re using to build a thins, the idioms of a language, etc.

But what if you need to compose a symphony?

Then the software industry isn't for you.

I'm definitely not saying it doesn't require dedication and brainpower and (in the right places) formal methods. But the overall creative process, and most especially the end product (and the aesthetics) of what we produce are about as far from a musical symphony ... as anything you could think of.

There's a good Steve Jobs quote about this, which I couldn't easily find, but which completely nails this distinction. Something along the lines of: "No - we're not here to build something that that people will look at in a museum hundreds of years for now. Very little of what we do will last for more than 10 years or so. It's about meeting people's needs in the here and now."

(Or to that that effect; I am horribly mangling the original).

That's not the point I'm making. Symphony as in complexity of the overall problem and synchronicity of so many moving parts (ie. so many instruments, multiple melody lines working w/ a far more advanced ruleset).

It's a very different thing to bust out a bunch of features for a consumer product w/ relatively minor concerns relating to load/perf and something that operates at bleeding edge scale and complexity.

OT: > learning music theory can harm someone’s ability to compose music. If you’re a pop songwriter, perhaps

This is a funny take on it as pop music is 99.9% just some basic music theory put in the shaker and than pressing the random shuffle button. The rest is mostly just dull and boring work.

That's the reason why after people once figured out how to actually do it are able to produce constantly hits for decades thereafter.

Let me amend that and say advanced music theory and composition. There is a definite thought out there that knowing too much impedes creativity.

As pop music is 99.9% just some basic music theory put in the shaker and than pressing the random shuffle button.

No it's not. No more than writing a successful novel is a matter pressing the random shuffle button on all the distribution of plotlines and clichés you've seen before.

Just to think that people who do good in leetcode alike tasks will not get things wrong is funny to say the least.

When I was young I also was pretty good at these interviews and loved doing coding contests and such for fun. However when I joined a big company I learned what really is hard about software "engineering".

It's dealing with legacy code, finding and fixing bugs in highly distributed systems, understanding tickets from customers, managing integration of different components, balancing tests to be enough but not to be too much.

In general the hard tasks are very rarely one specific well determined problem such as finding a node in a tree in the most performant way.

> It's dealing with legacy code, finding and fixing bugs in highly distributed systems, understanding tickets from customers, managing integration of different components, balancing tests to be enough but not to be too much.

Right, if you can't do any of those and can only do leetcode you will get hired as a junior. Do you think that juniors need those things? No, of course not, they need to learn that on the job. So juniors gets leetcode. Now, since all juniors can do leetcode, why shouldn't we require seniors to also know it? Otherwise we would hire seniors who are worse than the seniors we grow ourselves. You can say that seems like an arbitrary requirement, but it makes sense, and there is no lack of senior engineers wanting to get hired at FAANG. And getting X years of experience isn't an accomplishment, even the dumbest software engineer will get there after X years.

You didn't understand my point. It is that leetcode does not help at all (for 99% of jobs) because you are not faced with these problems.. you can of course claim that the juniors which excel in leetcode questions will be good at these other things I mentioned but I don't think there is much proof for that.

Of course you will gain experience anyways over time. But all your leetcode skills will fade into meaningless very fast when you see what the actual problems are.

I can do those leetcode bits. They just take time and energy. They can be fun in their own way, but I grew bored of them quickly. But all of the things you listed and leetcode have one glaring difference, collaboration. leetcode is a very solitary experience. You are basically picking at a puzzle by yourself and 'grind it out'. Yet all the other things you listed involve making everyone around you understand those bits. That is almost an entirely different skillset. Hell yesterday I sat back and just listened in a meeting to 3 different people state the issues they were having. I was able to help each one. Because 'been there done that', and another skill I picked up over the years listening to what everyone is saying. Not one bit of that was leetcode. But organizational and the same errors many devs stub their toes on. "oh go talk to so and so about that", "which error are you seeing in the log? oh that means blah blah blah, go talk to so and so and have them fix the wizzy wuttsy". Most issues in most organizations is either money, time, or knowing who to talk to. Big O, hash tables, CS style issues, are how you build the thing to sell. But day to day the business is run by people, time and money.

I have been meaning to go back and grind some of those problems out again. Just to refresh my memory on them. But notice I have to 'refresh my memory'? These problems usually do not come up. You are usually clicking some if conditions together and a few for loops. Nothing fancy. The interesting bits are figuring out someone elses framework using docs written in an afterthought and what 3 other methods do I need to call to fill out param 4 of this method just so I can get this thing to do what I want.

This line of reasoning makes no sense at all.

Imagine a math professor would be required to be as fast in answering questions regarding times tables as a child in third class. I bet you wouldn't be able to hire almost any math professors any more because almost all of them would lack this skill!

Nobody would be of course so stupid to judge a math professor by asking them questions about the times table.

Well, but one, and only one, industry is bonkers enough to do exactly this.

I'd be pretty damned suspicious of someone claiming to be a maths professor who couldn't tell me what seven eights are.

>No.

Oh look...a googler ;)

You nailed it, friend.

At a big company it's all about politics and optics. It doesn't matter what you actually accomplish, only what the people in power think of you and think you accomplished.

Which is part of the reason why the LC process exists -- to prop up the illusion that there's some kind of objective skill measurement happening.

And thereby distract us from the very central fact you have articulated.

> The aim is to hire people who won't get things wrong

The problem is that this almost inevitably leads to a decline of the company.

No.

I'd say it's more like a "Yes and no." But it's definitely not a binary. Your "No" characterization is partially valid. But only partially.

And what's a great what to introduce mistakes and fuck up an existing product or team? By being overly confident about one's binary "No" answers.

You'd want robots at that point. Or guillable people partaking and circle jerking in their own careerist cesspools. Better hope they don't get put in a leading/exploratory positions as the company dies a slow 30 year death.

> I've been delivering commercial products (that's the goal, no?) for over twenty years, regularly get high praise and top ranks in reviews, get promoted often including to "distinguished" and "chief" levels (always as a technical IC, not in management).

So… the industry is apparently working fine for you, right?

> But if I was in my 20s or early 30s, I'd be looking to leave tech entirely and go into something else where experience is actually appreciated and valued.

Yeah, sure. Not for everyone. It’s unfortunate.

> But if I was in my 20s or early 30s, I'd be looking to leave tech entirely and go into something else where experience is actually appreciated and valued.

I'm in my 20s and think about this a lot although I already moved to management (with a lot of software development, still) as well.

There's a great article [1] analyzing this problem (quotes from the article: "Professionals with higher cognitive ability drop out of STEM careers earlier and faster", "High-ability workers are faster learners, in all jobs. However, the relative return to ability is higher in careers that change less, because learning gains accumulate").

Knowledge depreciates a lot faster in software development than many other fields. That's why I really think about going into finance or sales (still fast-paced), but attending expensive top business schools and starting as an analyst with a low salary again is pretty rough after already building my current skillset. Currently feel a bit stuck with my career options right now. Money's still good and the work is fun, but working in a field that is set up to be a grinding mill as an IC is not an entertaining thought. High-tech projects will still be fun, I guess, but still definitely something to consider. Specializing early on may mitigate this.

[1]: https://whoisnnamdi.com/never-enough-developers/

Good assessment on the need to shift domain to ensure long-term stability. However, can you help me understand why you shortlisted finance and sales?

For sales: After attaining product-market fit and everything becoming more stable, it’s all about sales. Software development in the growth stage turns into an endless grind of features and bug fixes and is regularly seen as simply a cost. Sales is the mechanism that allows the business to get new customers, so this is something which has a higher impact in the growth stage.

For finance: Managing finance and deals is one of the most important aspects in any business. You can make the same money compared to tech without a ceiling and I’m personally interested in economics and financial topics.

Both have a quantifiable aspect (deal/fund size, new revenue/customers) that makes it easier to measure your impact on the business. This means that it’s easier to get a fair compensation - although bad performance will get noticed easily, too. And the knowledge in these areas compound, especially in sales.

On a personal note, I’m interested in psychology and economics and can build connections with others quickly, so these two fit quite well and I'm convinced that sales and finance are important ingredients for any type of work (philanthropic included).

Best of all worlds would be to build a MVP using software development skills until product-market fit is reached, then being able to grow customers using sales skills and then supporting further growth with external capital and managing an exit using finance skills. - In reality, these are all separate roles, but I'd like to be able to work in these other two areas, too.

I've looked at the other options, medicine, law, finance, your avg swe the best lifestyle, stress+time+creativiry to pay ratio, and flexibility around work.

You are dead on. I am burnt out from my previous position and jumping through hoops for people who don't know what they are doing.

The science degree was useful for when I did advanced math, before the finance industry figured it would just abandon complex math in favor of statistical learning.

There are definitely places that value non-formulaic advanced math. I spent most of the last 20 years (before retiring) doing signal processing, and some of it was very research oriented (no standard answers).

Don't get me wrong, I burned out for other reasons, but if you're looking for a job writing math oriented software, they are out there. Maybe consider finding a new area. Maybe take a break first though :-)

There are jobs that are not like this.

I’m very happy with my current employer. They’re hiring. Want an intro?

Sure, thanks, I'd appreciate it, or at least it would be interesting to see what is being done in that area.

Can you give me your email address (or Matrix, if you have it)? I’ll shoot you a message and we can have a quick chat about it. Plus, it seems like you could use a bit of good conversation :)

Who cares what companies want or trying to chase some huge payday. It’s all very boring.

What we do is a craft. Those things on lc are the foundations of our craft. I want to know everything about my craft, and a lifelong student of it, so I like sites like lc.

I’ll take it over trying read page after page of some big comp sci book.

Most of the interesting stuff is in papers and books, not on leetcode …

It sounds like that website is a shallow representation of this craft. A big part is working with stakeholders in a project, understanding needs and communicating what is possible. Only a portion of the craft is about writing algorithms.

In the industry computer science knowledge is useful on average once a month when you decide between a hash map or a vector. The hard part is figuring out what the customer actually wants.

> once a month

This is incredibly dependant on your company, team and role. I’ve been knee deep in data structures and algorithms for the last year. When I was at (FAANG) years ago I worked with people who did this stuff full time. You’ll find roles which use these skills in AI, AAA game dev, finance, operating systems and so on.

But probably 95% of commercial work is styling and wiring buttons. Even at big tech companies most of the work is plumbing. The skills you learn on leetcode are completely irrelevant in those roles.

Depends on where you are in finance. I work for a financial company an nobody I worked with was dedicated to algorithms. They seem to rather take the finance PhDs and teach them how to code rather than use developers for that stuff. The rest of us are just handling boring plumbing.

But probably 95% of commercial work is styling and wiring buttons.

We're in agreement that algorithms as such probably make up about 5 percent of industry work.

But the other 95 percent -- and I am talking engineering work, not product desgn -- is definitely not simply "styling and wiring buttons". And this is a very myopic view to have.

Yeah I don't know where y'all work, but data structures, algorithms, and design patterns are for breakfast lunch and dinner practically every day at my work. It wasn't so when I just started but as soon as I got out of a jr role all the problems has huge data sizes, things had do get done fast and all that so there's no escaping the fundamentals =\.

Programming definitely is a craft, but coding exercises are not the basis of it. The basis is the theory in the big comp sci books you are wary of.

I recommend Introduction to Algorithms [1]. Books like that can be really dry and hard to read, and they usually are, but they contain fundamental knowledge about computation that is the only way to solve some hard problems (and there are many hard problems that remain open). Leetcode problems, if they're any good, will simply be exercises based on the concepts in such books. But you won't understand the concepts just by solving the exercises.

My experience is that I spent seven or eight years coding in Prolog (that's how I roll, OK? Don't judge!) and while I had become skilled at it, I didn't really understand how it worked until I started my PhD at which point I really had to sit my bum down and read a whole load of stuff I didn't even know existed.

You'll probably say "what do I care? I'm not in academia". Yes, but you think of programming as a craft, right? And a crafts-person is happy to constantly improve his or her craft. Well, a PhD is one way to do that, sticking with industry for many years, if you can find the right positions, is another. But one way or another you'll eventually find yourself at a point where just solving coding exercises doesn't give you anything new. That's when you turn to the books. If you don't, then you should be concerned: it means you're not really advancing, not getting better in your craft.

I'd have a lot more to say about programming as a craft. Instead, let me point to Peter Norvig's timeless essay:

Teach Yourself Programming in Ten Years

https://www.norvig.com/21-days.html

And to this book by George F. Luger who introduced me to the concept of the "Master programmer":

AI Algorithms, Data Structures, and Idioms in Prolog, Lisp, and Java

https://www.cs.fsu.edu/~cap5605/Luger_Supplementary_Text.pdf

I'm also linking those for anyone else interested in that kind of thing. Happy reading.

___________

[1] It's online here:

https://edutechlearners.com/download/Introduction_to_algorit...

No idea if that's a legit download or not.

I hate it when someone calls it a craft. First off programming is one of the easiest engineering disciplines out there. That's why it's so easy to learn without a degree. It's like calling plumbing, "the art of plumbing." Sure it's a "craft" but don't be so full of yourself.

Also lifelong student? Have you ever felt that everything you learn is just the industry moving in circles?

If this was the case, then why are most applications full of bugs, including those written by trillion dollar corporations? To me, coding is a lot like physical construction - anyone who can swing a hammer can build a treehouse, but try to scale that to a skyscraper and it will go badly. At that point you need careful planning and lots of specialized knowledge to do it proper.

The things you describe, managing complexity, is hard because there's no science around it. There's no optimization method for calculating the best way to organize code. It's not even formally defined what "organization" is.

As a result everyone just makes up anecdotal "patterns" without proof that those patterns satisfy any quantitative "efficiency" criteria. Again this "efficiency" criteria doesn't really exist, we have some numerical metrics for measuring certain things but we can't really say definitively which is more organized the windows code base or the linux code base.

So in terms of these kinds of things. Nobody really knows who does what better. Does hiring people who can solve LC type problems result in more "organized" code? How can we know when we don't even have the word "organized" defined? The existence of this problem in CS doesn't make CS harder because everybody is basically ignoring this problem and just picking arbitrary solutions aka "patterns" to solve things.

Coding is like physical construction, unbounded by the rules of physics and therefore MUCH MUCH easier then engineering a boeing 747. Try learning building a 747 from a bootcamp. You can't. Coding bootcamps exist because it's freakishly easy to learn programming while engineering a 747 is freakishly hard, hence the lack of bootcamps for building airplanes.

It's like making legos to fulfill your goal. In the end the thing we build with these legos likely isn't the most theoretically efficient thing but it works and we didn't need super high intelligence to build it and we don't need someone smart either.

The thing with programming is this. It makes you feel smart. The reality is, your not.

> Coding is like physical construction, unbounded by the rules of physics and therefore MUCH MUCH easier then engineering a boeing 747.

No, this is exactly backwards: engineering software is much much harder than engineering a large airplane. The latter is bounded by laws of physics, which acts as a global coordinator between parts and teams. There are no global constraints in software engineering and therefore coordinating modules and teams are very difficult. We have to come up with a set of constraints to achieve these goals, but the search space for the correct constraints is almost infinite. Enforcing these constraints is another issue.

> Try learning building a 747 from a bootcamp. You can't. Coding bootcamps exist because it's freakishly easy to learn programming while engineering a 747 is freakishly hard, hence the lack of bootcamps for building airplanes.

This is a false equivalence. Coding bootcamps are akin to learning to assemble parts --- nothing like engineering software.

>No, this is exactly backwards: engineering software is much much harder than engineering a large airplane. The latter is bounded by laws of physics, which acts as a global coordinator between parts and teams. There are no global constraints in software engineering and therefore coordinating modules and teams are very difficult. We have to come up with a set of constraints to achieve these goals, but the search space for the correct constraints is almost infinite. Enforcing these constraints is another issue.

Your joking or highly highly misguided. Very few corporations have the ability to manufacture/designs planes. Tons of software engineering firms exist that hire coders out of bootcamp. Global constraints makes problems harder. Why? because these constraints are extremely hard to figure out. They can be modeled with differential equations but much of the constraints can only be determined through building an actual model and experimenting with them.

>This is a false equivalence. Coding bootcamps are akin to learning to assemble parts --- nothing like engineering software.

This is a true equivalence. Let me explain to you. THERE are many people who can't "engineer" software after they come out of a bootcamp. BUT there are tons of people who come out of a bootcamp and CAN engineer software. That's why people say you don't even need to go to school to learn how to program. You don't even need to go to school to learn how to "ENGINEER" it's easy.

Now for engineering a plane? I can assure you. An aerospace engineer can't EVEN engineer a 747 OUT OF UNIVERSITY; it's that hard. It's also fundamentally impossible for a plane engineering bootcamp to even exist due to the sheer challenge of it.

You have a misguided notion of how hard software engineering is. Software Engineering is Ironically the easiest "engineering" discipline out there yet one of the highest paid.

> Very few corporations have the ability to manufacture/designs planes.

So what? The reason could as well be market dynamics. By the same reasoning we could also argue that software engineering is the hardest, because it is the highest paid one.

> You have a misguided notion of how hard software engineering is.

Software engineering is not programming, just like aerospace engineering is not assembling a plane.

> An aerospace engineer can't EVEN engineer a 747 OUT OF UNIVERSITY; it's that hard.

Let me rewrite that: A software engineer can't even engineer a Google out of university; it's that hard.

I don't think this discussion is being fruitful to me. I hear personal attacks instead of counterarguments to the ideas I presented. So, I won't be replying further.

>I don't think this discussion is being fruitful to me. I hear personal attacks instead of counterarguments to the ideas I presented. So, I won't be replying further.

Apologies for you thinking this it's not my intention to personally attack you, in fact I didn't. I think you're just perceiving it this way because my language is very to the point.

Saying you're misguided when you actually are is not an insult btw. It's not your fault or some kind of attribution to your intelligence when I say so. It's simply you are misinformed. Likely you are also very young.

Either way... I myself am a more logical person so "personal attacks" don't effect me if the possibility of new knowledge being imparted to me is greater than zero. This is the logical way of perceiving things. You obviously are less logical so your reasoning can be forgiven.

>So what? The reason could as well be market dynamics. By the same reasoning we could also argue that software engineering is the hardest, because it is the highest paid one.

lol market dynamics. No the reason is because it's harder. There's only two companies in the world that can build passenger airliners. There is tons of room for more competition. The duopoly is held because very few companies can build these things to the scale and speed as boeing or airbus. China is making a huge endeavor to gain these skills and after several decades their planes are still not ready for mass production. See below for evidence:

https://www.youtube.com/watch?v=4n3R1xQzs3E

This isn't the only example. Let's go with semiconductor manufacturing. Currently there's a shortage of computer chips. The "MARKET DYNAMICS" demands for tons and tons of companies to fill the space... but guess what? China and the US don't have the knowledge or the know how to fill the gap. TSMC and ASML two companies from Asia and Europe respectfully are just a few companies out of a handful that can do build chips at the 5nm process. Intel is still behind.

Meanwhile no company on the face of the earth has a monopoly on "software engineering." Why? because it's easy. Anybody can do it.

Take a look at this: https://en.wikipedia.org/wiki/Software_engineering#Tasks_in_...

There's zero science, axiomatic proofs or empirical evidence that is part of the definition. It's all just "planning" guidelines masquerading as some kind of mathematical formalism. It's not. It's just a made up series of steps for creating software. I can easily make the same set of formal rules for company bylaws or planning some event.

>Software engineering is not programming, just like aerospace engineering is not assembling a plane.

Software engineering? You mean agile? lol. or simple stuff like unit testing? Even agile isn't part of any theory. and best practices like testing are easy. These are just made up formal rules that we "think" work. Let me be honest with you, if engineering practices from software were applied to other forms of engineering you would be laughed at. Also people would begin dying if agile was used to hack on features onto an airplane. See the boeing 737.

>Let me rewrite that: A software engineer can't even engineer a Google out of university; it's that hard.

You realize google doesn't care what university you went to or even if you went?

https://analyticsindiamag.com/why-google-believes-you-dont-n...

Google is built and maintained by many people who never went to university. Additionally do you know about the founder of duckduckgo another company centered around a search engine? You know what "engineering" knowledge he used to create duckduckgo? None. He got a physics degree from MIT. Learned programming by himself. Likely didn't read a single book on "software engineering"

With you for the most part, but can’t get behind your analogy.

> Try learning building a 747 from a bootcamp. You can't.

Yeah, try doing that with an engineering degree. You can’t.

Try grabbing a random Boeing engineer and get them to build a 747. They can’t. No one can.

Okay, I should be more charitable. You mean can’t contribute to a portion of the 747 project? Yeah, college isn’t necessarily going to help you much either, and you might be surprised what a smart person off the street can do… there’s a really good chance your boss just has a bunch of spreadsheets for all her maths. Yeah in the grand scheme of things you’ll have to learn how to do that too, but it may not be the barrier it seems.

I’m a SW Eng, but did and entry level EE gig, and basing my experience on that. College did not prepare me at all. Engineers routinely enter industry without knowing what a relay is (and we used ladder logc!). Btw, we had self taught non-college educated “engineers”… they'd usually be talented operators that knew the machine like the back of their hands. So that’s basically an ME without a degree.

I did a stint on an F-16 project after switching to computer engineering, and it was the same shit. Almost everything was learned on the spot from the veterans or google for general stuff.

So yes, I could have worked on F-16 off the street, as well as done EE work and it really seemed like my ME friends were grinding out the same BS.

Where are all these super special engineering people you so admire? Some of them do get very specialized education, but we were talking BS Engs.

P.S. I do agree about the accessibility of programming. There actually are many topics that are hard to self learn, for example comp arch would be very challenging without a good professor. There’s many others, that’s just what sticks out as “thank God I went to uni so I could learn X”

> With you for the most part, but can’t get behind your analogy.

I think the analogy works. No single engineer whether out of university or not can build a 747.

However a single person built a search engine. Duckduckgo. The person didn't even have a degree in software engineering. He had a physics degree.

I see your point. Let me put it this way. Somewhere in building the F-16 or the boeing 747 there is a form of theoretical modelling that must be done as a fundamental thing in order to build it. You need to calculate the flight dynamics and mathematically model the control system using math skills that cannot be obtained by attending a bootcamp.

Most of these skills can only be obtained through several years of practice, and a bootcamp doesn't offer that. Granted there are many parts of engineering a 747 that don't need these deep design skills so you can get away with not knowing what an ODE is while being an engineer.

But again, these complicated problems tend to be handled by well educated and experienced specialists. The reasons behind why it's not possible to do for the 747, but is with a search engine deal with complexity. There's far too many pieces for one person to handle, no matter how skilled.

For a single person to be able to do everything (not familiar with your examples, so I can't speak to the truth of it, but accepting your premise), the implementation must be sufficiently simple. You CANNOT provide an adequate solution to a slew of technical problems by yourself. There are many topics in SW Eng that CANNOT be done by a single person. Impossible. You can build a plane by hand by yourself. People do all the time. I had a boss that did. Sure he's buying parts and not eg designing the body himself, but no one ever really did.

At one point there were no planes, but over time we learned to do it better and better. At every step engineers were learning the ropes from industry veterans, then adding their own innovations. Not that different from a guy putting together a plane from parts. You could point to more complicated areas where harder technical concepts are applied, but that really just works the same. You learn x software, and y methods (again from the veterans NOT from Uni), then you add your innovations.

You think Boeing is designing all their parts, on one team? No it's mostly people cobbling together parts from suppliers and other teams, digging under the hood for some things, tweaking similar designs, managing, "business stuff", ect. That's the vast majority of engineering, even outside of software. A high percentage of people won't touch the stuff they learned in school, or just a tiny piece of it. They're getting most of their information from the professional greybeards from within their industry.

I do agree that things are a bit different in software engineering, but not by as much as you seem to think. We could probably get a lot of traditional engineering prospects off the ground with an intensive camp. This makes a lot more sense in software for a variety of reasons (IMO mainly because there's SO MUCH of this kind of work to do), but I don't agree that it's impossible in other engineering domains.

It seems like you'd have to make a comparison that is not apples to apples, eg. comparing a master/phd educated, highly-specialized ME to an entry level software engineer. A better comparison is comparing a run-of-the-mill developer to a basic ME working in a plant. Things aren't so different there. You can also compare a specialized SW Eng, eg. working on algorithms themselves to the kind of aerospace engineers your picturing. Things don't look so different then, I think.

>But again, these complicated problems tend to be handled by well educated and experienced specialists.

That's my point. In software engineering these specialists aren't required. Like actual deep mathematical knowledge isn't needed for software engineering.

>They're getting most of their information from the professional greybeards from within their industry.

Of course, I never disputed this. However there is a foundational knowledge in say something like ME which is more reliant on schooling. This foundational knowledge is required to understand the greybeard. For example kinematics and calculus. Just getting up to that point requires at a minimum.. two years of training in school.

Plenty of software engineers don't know calculus or trig. That much I can assure you because it's rarely required.

I don't dispute that deep mathematical knowledge isn't needed for software. It isn't really needed in much of engineering. Plenty of high school level students can do trig and algebra. You can get by just fine in much of the engineering world, just like software, with bare minimums. Linear algebra, trig, even basic diff eq and calculus is relatively easy to pick up independently IMO. Plenty of books, exercises, videos, ect. Having taken math at multiple universities, including community colleges, I can't tell much difference between the programs. It didn't seem like anyone else felt otherwise. Going to college to learn basic math would be a waste of money, I think.

> That's my point. In software engineering these specialists aren't required.

That's not really true. I mentioned this in my comment. There are many areas of software and computing that DO require specialists. Elite teams or team members that tackle really really hard problems that much of the field then uses. So there's really no difference there at all.

Do you work in ME? It sounds like you have a glamorized idea of what a lot of other engineers do. I can assure you that the vast majority of them are not using specialized knowledge. It doesn't really seem that different to me. I can assure 100% that it's the same in EE, because I've done that, and it was almost exactly the same. (of course, it's fair to point out the similarities between EE and CS, but again all my ME friends reported the same kind of stuff).

>It isn't really needed in much of engineering. Plenty of high school level students can do trig and algebra. You can get by just fine in much of the engineering world,

A certain amount of People can get by, but the project itself cannot get by without a minimum people on that project knowing this stuff.

For your typical software project, the entire project can get by without anyone knowing anything from algebra and beyond.

>Linear algebra, trig, even basic diff eq and calculus is relatively easy to pick up independently IMO.

Less likely for people learn this stuff outside of a school. It can be done without school but the likelihood of learning these things without school is low because learning these things is about 10x harder than programming. Developing the intuition and familiarity with this is very rarely done independently.

Additionally, these are the bare minimum required for engineering. Complex analysis, control system theory, kinimatics, physics, circuit analysis and much much more are required for systems engineering. And almost nobody starts learning this stuff as a "hobby." Basically people pick up learning django or rails as a hobby or something along those lines.

>Do you work in ME? It sounds like you have a glamorized idea of what a lot of other engineers do.

I'm EE, switched to CS after graduation and I work in embedded systems with mechanical engineers and other EEs.

Yes the day to day doesn't require solving an ODE. But the basic knowledge is required in some aspect of the project. The same is NOT true for software.

>There are many areas of software and computing that DO require specialists.

Very few. ML or Data is mostly what I see but you're average web development shop has sw guys who are roughly homogeneous in terms of skills. Any specialization is domain knowledge as in he's the guy that coded that maze so he's the guy that knows it best.

There are "specialists" but the crossover is so close that all these specialties can combine and you encounter tons and tons of people who are "full stack" engineers.

One of the best analog engineers I worked with was not an actual electrical engineer in title. He was a technician without a degree of any sort that worked on electronics projects at home for fun. He’d often be frustrated at the solution the actual electrical engineers gave him to implement and test and would fix the design. Sure, he couldn’t program an FPGA or write DSP code, but he had a solid grasp of analog design that a lot of electrical engineers lack.

Thumbs up to that engineer. How many of those people exist in the industry though? I would argue far far far fewer than the equivalent in software engineering.

Oh yeah, we had this guy in enterprise. Total hardware wiz. Did horribly in college. All that homework-doing and test-taking got in the way of all his fun projects. So he just limped across the finish line and got a gig from a professor he'd worked with closely. Pretty cool technical work, guessing the pay was so-so, but doubt he gave a fuck.

For people interested in the comparison between “real” engineers and software engineers (as in this thread), Hillel Wayne wrote an outstanding series of blog posts summarizing a bunch of interviews he did with former “real” engineers who turned software engineers. I found it extremely interesting.

https://hillelwayne.com/post/are-we-really-engineers/

"If this was the case, then why are most applications full of bugs, including those written by trillion dollar corporations?"

No-one ever seriously asked me how to make a program bug free. They also didn't ask me to use formal methods or prove any properties of the system I'm asked to implement. Hell, I can tell that I want to spend time developing tests and they say no, nah, we don't want that. Everywhere I've been it's been more important to deliver stuff quick and cheap than it is to make it perfect. Maybe places where extreme focus on quality do exist, and you only hear about them when the extremely unlikely catastrophic failure happens. But that's not the norm.

Analogies to real world rarely fit but I think most software is like most construction: houses and flats and small commercial buildings where you can and regularly do get away with shoddy stuff and blemishes. The usual thing complaints are about are schedule and budget overruns, and then when everything is done, all the faults and rushed parts they find... Guess what, they like cheap and fast in construction too. In every place I've lived, I could point out many many little snafus from walls that aren't quite straight, misdimensioned boards and panels and other things that just don't quite fit, design issues such as doors obstructing important paths or not having room to fully open, etcetra.

And you get away with it because your house is not going to fall apart because of a missing nail. Likewise for most software. Just another bug? Fix it and move on. Or maybe even leave it in if it's not catastrophic and there's more important things to do. The bar for quality is generally pretty low.

Exactly. Try open source development on a boeing 747 or even agile style development. @svantana Would you step onto a plane that was developed this way? The bar is low as hell.

This is an especially good analogy when you look at mass home builders and buyers' frequent complaints about shoddy materials and workmanship, e.g. https://old.reddit.com/r/RoundRock/comments/ae8p5c/what_is_y...

Anaolgies are deceptive. They don't prove anything but they lead you to perceive something to be more real even though no argument was made for proof.

So houses are made from shoddy workmanship. Software is also made with shoddy workmanship. How does this analogy prove that software engineering is not the easiest engineering field out there?

I would argue that it proves software engineering IS the easiest engineering field out there because you can get away with this shoddy workmanship. In fact the engineering process of software engineering are centered around shoddy workmanship and throwing in and developing features without any sort of plan. See agile for more info on this process.

I used agile before it was cool, back when it was a website and some rebel engineers frustrated at 6-month point patch cycles. In those days everything was a skyscraper, even getting MS Word installed on your company desktop. I hate what it's become and you're preaching to the choir. But some big projects do take real engineering, and coordination, and careful weighing of options before moving forward.

I've worked on these projects, they still exist but are rare. You'll find most of these projects are in high end defense or other embedded systems projects that are highly, highly connected with building hardware.

Outside of this kind of stuff, software engineering is easier than most other forms of engineering due to an accepted lower bar of quality.

Been doing this for 30+ years. "Craft" is an ok way to put it. It definitely isn't the "easiest" engineering disciplines - all engineering is difficult otherwise we wouldn't call it engineering. If you think it is easy, you haven't done anything worthwhile, sorry.

To bad engineers, I can see how it looks easy and that it is "moving in circles". It is still a relatively new discipline, and as such, still finding a lot of the process, tools, and techniques that other disciplines have developed. Plus Moore's Law and its ilk change things constantly.

>If you think it is easy, you haven't done anything worthwhile, sorry.

LOL this is an insult. Let me put it this way, you're right but I can bet you haven't done anything worthwhile either. Anything you've built as a software engineer, I can 100% build as well. There is nothing you can do that I can't as a pure software engineer. In fact likely everyone on this thread can build anything you've built and likely do better as well.

But let me be clear. If you programmed CAD software that can simulate an entire boeing 747 flying through the air... that is a feat that not many software engineers can do. But this doesn't count because it's combining two engineering disciplines (even a PRB renderer doesn't count.

Something like an OS would be an example of a pure software engineering approach.

Also I never said software is easy. I said it's the "easiest." Big difference.

IN ALL of engineering it's highly unlikely for all engineering disciplines to be equally hard. highly highly unlikely. All engineering disciplines must overall stand at some general point in the challenge spectrum. You could say the answer is too complicated to answer as there are jobs in say chemical engineering that are much harder than certain jobs in mechanical engineering and vice versa but regardless a GENERALITY of hardness exists.

What engineering discipline in your mind is than the easiest if not software engineering? Tell me. What other engineering discipline to practitioners don't require any schooling are hired without a degrees and you can easily form a start up around with less effort? Why don't we see a bunch of spaceX startups but see a ton of startups building some stupid dashboard for a niche?

I'll give you a hint. Because when you compare rocket science versus computer science, one of these fields is GENERALLY easier.

> I can see how it looks easy and that it is "moving in circles". It is still a relatively new discipline, and as such, still finding a lot of the process, tools, and techniques that other disciplines have developed. Plus Moore's Law and its ilk change things constantly.

How it looks? I've been in this industry for years. I can assure you it's not a "look" thing. It's a TRUE thing. The industry does move in circles.

There's no mathematical theory on how to organize code so we make shit up and call them "patterns" but there's ultimately no actual proof that one pattern is better than another and we're not 100% clear about the tradeoffs diving in. That's why the industry moves in circles. It oscillates between two solutions and it can't figure out which is better.

For what use case is a monolith better or a microservice? What software design pattern is actually better for what use case? Can you plug it into an formal equation and optimize the best design pattern to use for a certain case? You can't... because no theory exists.

But no theory needs to exist. You can hack a half assed solution and that's really all that's needed. Even if you don't "hack" a solution together nobody can really prove whether your "designed" solution is better. A stupid engineer can design something and think he's a genius but without theory nobody can prove whether his design is the best one possible.

And that is why software is easy. Anything goes. It's like building 1/32 scale model of the eiffel tower out of toothpicks. Is there a theory behind it? No. Is it easy to do? No. Can anybody do it? Given enough time, Yes.

> But no theory needs to exist. You can hack a half assed solution and that's really all that's needed

I don't understand your reasoning. You say that it's possible to "hack a half assed solution" that somehow works and from that you conclude that software is easy (or the easiest, doesn't matter)?

Aren't you contracting yourself? If software is easy why do you produce a half-assed solution? If it's so easy why isn't your solution of high quality like the 747? Maybe it's not so easy to write cheap, bug free, portable, maintainable, compatible, little-resource-consuming, high-performing software?

I can also build a half-assed airplane. It will crash often, not do what I wanted, and I will use a lot of off-the-shelf components (engine,...), just like modern software... That must mean building airplanes is easy, right?

Edit: It would be more correct to say it like this: Creating software is hard and poorly understood at the moment. Even worse, people writing software are not trained well. But since the expectations of our customers are low (compared to the expectations we have to, for example, an airplane), the market tolerates this.

Edit 2: By the way, I agree with most of what you have written about the industry moving in circles, half-assed solutions, using patterns and frameworks without any deeper understanding. But that's actually proving that software engineering IS hard. (or maybe it's easy but nobody cares)

>Aren't you contracting yourself? If software is easy why do you produce a half-assed solution?

That's why it's easy. Finding a formal theory for software organization is hard so it hasn't been done yet. We make do with design patterns and many of those patterns are outright mistakes.

As it stands without "Computer scientists" establishing a formal theory on this... Software engineering is a shot in the dark and therefore easy.

>I can also build a half-assed airplane. It will crash often, not do what I wanted,

An airplane can only crash once. And when it crashes, people die. That's why no airplane is ever half-assed. Building an airplane is hard because of these requirements. Building software is easy because the requirements ALLOW for it to be half assed. Does my OS crash once a day? Still somewhat useable... Does my plane crash once a day? Holy shit.

>Edit: It would be more correct to say it like this: Creating software is hard and poorly understood at the moment. Even worse, people writing software are not trained well. But since the expectations of our customers are low (compared to the expectations we have to, for example, an airplane), the market tolerates this.

Hence why Software engineering is one of the easiest engineering disciplines out there.

>Edit 2: By the way, I agree with most of what you have written about the industry moving in circles, half-assed solutions, using patterns and frameworks without any deeper understanding. But that's actually proving that software engineering IS hard. (or maybe it's easy but nobody cares)

I would argue that this is more, computer science is hard rather than software engineering. The development of new techniques and greater understanding is the domain of science and academia. Engineering is about solving existing problems with existing techniques. Software engineering as it stands is easy.

What about safety critical software? For example software running inside airplanes, rockets, etc. Is that also easy, or it doesn’t count because it’s cross discipline? Although I would guess that many of those developers are indeed software engineers and not aerospace engineers by training.

>What about safety critical software? For example software running inside airplanes, rockets, etc.

There's two ways of handling software that's safety critical. For software that needs an extreme level of safety... formal methods are employed to prove correctness and that software is bug free. For this part of computer science the foundational theory is well established. This part is really really hard which is why 99% of software engineers don't even know what I mean when I say the word "formal methods." It's so different from traditional software that it's never ever referred to when people use the term "software engineering." We have a rudimentary form of it in the form of type checking in our programming languages.

But there's another part of it as well involving empirical testing. This is popular in the industry and engineers use the term unit testing or regression testing to refer to it. It's a shot in the dark. Basically taking a couple test samples out of an huge sample space of possible tests and saying if those samples work then likely the whole thing works. IF you want to prove your program correct using this method you would have to run every single possible test that exists on your program. It's untenable so we informally rely on a statistical phenomenon of taking a sample of tests out of a huge sample space.

This is the most common way of creating safety critical software that everyone uses because it's easy. Don't mix tediousness with easy. Using this methodology is very tedious, but I would argue quite easy.

Also redundancy and fail-safes in logic are used throughout the system for safety critical software. This again is easy to implement but tedious.

>Although I would guess that many of those developers are indeed software engineers and not aerospace engineers by training.

Yeah most of the mathematics in this case is modeled by system engineers or other engineers that are more specialized than the math is handed down to the software guys who only need to understand the equations but they don't need to understand how to derive those equations.

During testing the software engineers and hardware engineers would have to work together to make sure the software operates the hardware correctly. If the hardware is simple or well established and accessible often the software engineer can do the testing alone.

Sometimes the engineer of the physical system itself just programs it himself. Alot of non-software engineers are like this because software engineering tends to be easy so they can just learn how to program.

I agree that formal methods probably isn’t as well known as it could/should be.

> Also redundancy and fail-safes in logic are used throughout the system for safety critical software. This again is easy to implement but tedious.

I wouldn’t call implementing redundancy and fail safety for a fairly complex system easy though. Tedious, yes. And tedious but easy probably could describe lots of other engineering work as well, not only software.

> Sometimes the engineer of the physical system itself just programs it himself. Alot of non-software engineers are like this because software engineering tends to be easy so they can just learn how to program.

They might believe that it’s easy to write some software that in some way solves the problem but in my experience they don’t always engineer good software, and don’t always realise that their small part of the program has to work together with a huge amount of other software. Not that all software engineers do this either..

>I wouldn’t call implementing redundancy and fail safety for a fairly complex system easy though.

What's the cutoff for IQ then to implement a redundancy. Is there really a mediocre software engineer who can't do it. My argument is with a lot of effort any software engineer can do it. And if anyone can do it.. it's easy.

>They might believe that it’s easy to write some software that in some way solves the problem but in my experience they don’t always engineer good software, and don’t always realise that their small part of the program has to work together with a huge amount of other software. Not that all software engineers do this either..

As I've stated before. There's no logical theory behind program organization. How you integrate software together is mostly gut level arbitrary decisions and many times those decisions come out wrong and people make workarounds to fix things.

It all usually ends up working in the end. It may be ugly but it works and then everyone rewrites and the cycle begins anew.

Nobody in this area of software truly knows what they are doing. Hence why it's easy.

Let me be clear about what I mean by easy. Easy means anyone can do it. If a lot of hardwork and problem solving effort is involved... it doesn't matter and it's still easy because anyone can do it.

What you wrote confirms what I thought, sorry. You seem incredibly bitter, and I'm also sorry that you feel that way. If software isn't for you, it isn't for you. I come from an era when I was considered a weird nerd because I understood and liked "programming". The idea that everyone should like it is bizarre and foreign to me.

There is worthwhile software, and I have written some. But worth it is in the eye of the creator, and so I maybe I find worth where you don't.

What is the "easiest" discipline is a nonsensical question to me.

>If software isn't for you, it isn't for you.

See this is a straight up insult. How do you know software isn't for me? You only say this to be manipulative and insulting. I love software, I'm just not delusional. Software is easy.

Let me tell you the extent in which I love software, I study haskell in my freetime. I study formal methods. I study graphics programming all of which are unrelated to anything practical to my current career trajectory.

>There is worthwhile software, and I have written some. But worth it is in the eye of the creator, and so I maybe I find worth where you don't.

I defined it in a way where it isn't defined by the eye of the beholder. What "worthwhile" software have you written that very few people in the industry can write? I bet you all the stuff you wrote, any mediocre software engineer can write. Which illustrates my point.

>What is the "easiest" discipline is a nonsensical question to me.

Of course it's nonsensical to you. How convenient. Because answering this question would defeat your argument or display how much knowledge you lack for other forms of engineering. The answer is: "software engineering"

It's like refusing to answer the question which is harder: Calculus or algebra? Well they are two different subjects and I am a logical automaton I can't determine which is harder so I am labeling the question as nonsensical even though the entire face of the earth OBVIOUSLY knows calculus is harder.

Well guess what you're not a robot. Don't hide behind that as an excuse. Calculus is harder than algebra just like how software engineering is the easiest engineering discipline out there.

Even "worthwhile" software that you write is easy.

Calculus and algebra were easy. I know you haven't written worthwhile software (yet), since you say writing software is easy. Write something worthwhile and then come back and let me know how easy it was.

Although, to be fair, some worthwhile software is easy to write, it's just figuring out what to write is really hard ... but that's one of the reasons why the discipline is hard!

>I know you haven't written worthwhile software (yet), since you say writing software is easy.

lol. You're a genius. I've stated this multiple times. Software engineering is EASIER than other forms of engineering. This is a bit different than just being "easy" and while I've used the word "easy" you know my intent.

I am also absolutely positive all the worthwhile software you have or yet to have written, any mediocre software engineer can do. Just name all the stuff you done. Anyone can do it.

Let's look at your stuff: https://github.com/gilbitron This is you right?

Well when I think of impressive "worthwhile" software I think in terms of kernels, 3D rendering engines, a compiler that kind of thing. Those are things I would argue that actually promote your argument as less software engineers know how to program this stuff.

But looking at that site looks like you mostly do typical generic webdev stuff. Web dev is one of the easiest areas of software engineering. Also you're a vue guy and php. Vuejs is the typical choice for old school web dev guys who do php. I assure you all the stuff you built, anyone can do it. Doesn't even come close to "worthwhile."

Because anyone can do it, that is why it's easy. You can call it hard. But that's fine it just becomes a word game. Let me put it this way, ALL the software you have done may be "hard" but it's easy enough that any mediocre software engineer out of bootcamp can implement everything you wrote from scratch.

>Calculus and algebra were easy.

Nowhere near as easy as programming. The math involved with engineering goes much deeper than highschool algebra and calculus. I know you haven't done anything worthwhile in engineering besides webdev because you called it easy.

> And that is why software is easy.

> That's why it's easy.

> Software engineering is a shot in the dark and therefore easy.

> Software engineering as it stands is easy.

> Nobody in this area of software truly knows what they are doing. Hence why it's easy.

> Let me be clear about what I mean by easy. Easy means anyone can do it. If a lot of hardwork and problem solving effort is involved... it doesn't matter and it's still easy because anyone can do it.

Seems like you think it is easy.

And no, that's not me that you linked. Although I have done webdev work in my career, and only easy webdev work is easy. There is plenty that is difficult in webdev.

Also I've created a 3D renderer from scratch (a complete 3D engine, in fact, including networking), a flight simulator, an ISAR simulator, software for force feedback, and a genetic samples assembler - and that's just the stuff from before stack overflow existed.

>Seems like you think it is easy.

Let me repeat it a bunch of times so you get it: Software Engineering is Easier than other forms of engineering Software Engineering is Easier than other forms of engineering Software Engineering is Easier than other forms of engineering Software Engineering is Easier than other forms of engineering Software Engineering is Easier than other forms of engineering Software Engineering is Easier than other forms of engineering

Look you can either understand my point or play stupid games.

>Also I've created a 3D renderer from scratch (a complete 3D engine, in fact, including networking), a flight simulator, an ISAR simulator, software for force feedback, and a genetic samples assembler - and that's just the stuff from before stack overflow existed.

LOL, A 3D engine from scratch with networking impressive but arguably is doable by anyone. It also depends on whether when you created and what version API you used to interface with the graphics card. Prestack overflow likely means the engine was quite trivial.

But your other stuff only proves my point. Most of your projects are impressive ONLY because they combine other aspects of engineering together. Your stuff intersects with kinematics, aeronautics, biology, embedded hardware sensors, electromagnetic theory. This stuff is hard, the software by itself is easier.

>Although I have done webdev work in my career, and only easy webdev work is easy. There is plenty that is difficult in webdev.

I've been a webdev for a good chunk of my career. I've also done work similar to what you've done in your examples. You skim over general truths shooting for only the technicalities at your convenience.

Webdev work is generally the easiest form of software development and one major reason for it is due to lack of intersection with other aspects of engineering. WebDev also currently happens to be the sector of software with the most jobs and it contributes to the fact that software engineering is one of the easiest disciplines out there.

I'd call plumbing a craft, same with auto mechanic. I admire someone who put in the years to not only fix the thing, but knows ridiculous details of certain kinds of bolts or whatever. That's having a hobbyists perspective, and the enjoyment of something just because you're fascinated by it.

Obviously, some would consider it a waste of time. 90% of their colleagues would say, "I don't get paid to know unnecessary stuff about the bolts. I get paid to screw this to that according to this diagram." Which is what commercial software work is. Different thing from being a hobbyist.

>I'd call plumbing a craft, same with auto mechanic.

The point is that the plumber himself wouldn't call himself a craftsman. He doesn't label himself as some sort of artist and prance around like an arrogant prick thinking he's better than those janitorial engineers who are complete hacks.

>Different thing from being a hobbyist.

Yeha nobody does plumbing as a hobby. I'll give you that. I think you're more referring to "Computer science" here which is a bit different.

How much do you know about traditional engineering? I have family and friends who work as engineers, and from what they have told me software has a far larger problem space and the software engineering process is far more rigorous.

Traditional engineers are generally doing the same-ish thing over and over, and the number of possible things they can do is severely limited in comparison to software. Safety is also not as big of a deal as cost. Any idiot engineer can create something with an insane factor of safety, it takes a good one to design something that is safe and cheap.

If you want to compare very complex/rigorous engineering projects like airplanes you should compare them to things like Google. Software and traditional engineering are both rigorous at the highest levels, though not in the same way since software is so much more flexible and has a larger problem space.

A lot. I work at the intersection of all engineering disciplines.

>I have family and friends who work as engineers, and from what they have told me software has a far larger problem space and the software engineering process is far more rigorous.

Software engineering is and everyone agrees with me, 100 times less rigorous. Only software has this culture of releasing something than issuing patches later.

As for "problem space" this is more defined by a product. The product is the problem space and programming is one solution to solve a problem. Granted programming is more versatile than other forms of engineering in terms of solving certain problems but this only lends to the fact about how much easier software is hence the desire to convert analog stuff to digital.

Flexibility is an indicator of easiness.

>Traditional engineers are generally doing the same-ish thing over and over, and the number of possible things they can do is severely limited in comparison to software. Safety is also not as big of a deal as cost. Any idiot engineer can create something with an insane factor of safety, it takes a good one to design something that is safe and cheap.

>If you want to compare very complex/rigorous engineering projects like airplanes you should compare them to things like Google.

I mean sure, this doesn't change the fact that software is the easiest of all engineering disciplines.

>If you want to compare very complex/rigorous engineering projects like airplanes you should compare them to things like Google. Software and traditional engineering are both rigorous at the highest levels, though not in the same way since software is so much more flexible and has a larger problem space.

Fine let's compare the rocket industry and automobile industry with software. Are either of these industries over loaded with a barrage of random ass startups or is software the only industry with this stuff?

You are trying to directly compare software with traditional engineering which doesn't really make sense. Traditional engineering has a lot of constraints which software doesn't.

> Only software has this culture of releasing something than issuing patches later

This has nothing to do with the rigour of software engineering. The process for releasing the initial software can be very rigorous, with a conscious decision to follow up with a patch or second release.

The nature of software allows this behaviour, whereas traditional engineering doesn't. The fact you can't release a day 1 patch for a building doesn't mean that the process for designing and creating a building is more rigorous.

> Flexibility is an indicator of easiness

How so? Flexibility means more ways to shoot yourself in the foot. It means you can easily implement something that works for now, and fucks you over later on. It's harder to do that with a physical construction because there are a lot of constraints. Physical construction has physics as guardrails, whereas software has unbounded complexity.

> Are either of these industries over loaded with a barrage of random ass startups or is software the only industry with this stuff?

How is this indicative of rigour? Yes, software has a lower barrier to entry. That doesn't mean that software engineering in general has less rigour.

A lot of software is written haphazardly without process, but I wouldn't classify that as software engineering because there is no engineering process there.

I'm just comparing the hardness. Software engineering is easier is my argument. The patchy nature of software makes it easier.

>How so? Flexibility means more ways to shoot yourself in the foot

True but people do so anyway. People in software repeatedly shoot themselves in the foot all the time than shrug it off. Oh it's just a bug. Hence the easiness.

>How is this indicative of rigour? Yes, software has a lower barrier to entry.

Rigour is another argument, though software definitely has less rigour. But my point is software engineering is easier. Doesn't low barrier to entry mean it's easier? It's like literally a synonym.

>A lot of software is written haphazardly without process, but I wouldn't classify that as software engineering because there is no engineering process there.

That's why it's easier. The "software process" is not really required. It's like an optional thing. Plenty of software shops prioritize speed over planning.

It sounds like your argument is that writing ANY software is easier than traditional engineering, which I would agree with but I think it's a poor comparison.

Most software shops aren't practising engineering, so to compare them to traditional engineering seems odd.

Software engineering is poorly defined. You say most shops aren't practicing engineering yet every software guy who works at these shops has the title "Software Engineer."

Let's dispense with the linguistic technicalities. Software, whether you want to attach the word engineering at the end of it or not is easier than other forms of engineering.

I agree software engineering is poorly defined, but I don't think it's just "linguistic technicalities".

There is an enormous difference in the work between shops that hack code together and those that have well defined processes.

The former is nothing close to engineering whereas the latter is very much engineering.

Also on the title thing, I think they're basically meaningless everywhere. Engineering grads will also call themselves engineers regardless of the kind of work they do.

The titles are as meaningless as the process itself. I understand what you're getting at. Everyone understands.

I'm saying these processes are pointless. They're are made up. An arbitrary set of methodologies or plans to execute certain things made up by mostly project managers.

It's like company bylaws or procedures for scheduling an event. Engineering processes are usually designed around some form of mathematical model or statistical phenomenon. This is not the case for software. Software processes aka Software engineering is just a made up set of arbitrary planning procedures.

Shit like kanban or poker planning comes to mind.

Things like Kanban were not at all what I was thinking of.

Software processes are designed with mathematical/statistical backing when needed. For example, A/B testing, anomaly detection and merge queues.

> arbitrary planning procedures

I don't think this is an accurate description. In traditional engineering the main focus is: does it work and is it cheap? In software, both of these are usually non-issues so things can vary a lot more.

For example, recently there was a blogpost by a company about not doing code reviews by default to allow them to move faster [0]. They are making a conscious effort to optimize their process for speed. Other companies (Or even teams within companies) will make different optimizations. A service that must be highly available may have 100% test coverage as a requirement, etc.

I suspect you will call this arbitrary, but I see these process decisions as conscious choices. The fact these aren't grounded in mathematics or statistics is not a big deal to me because the goals/focus are more complex than does it work and how much does it cost.

In software everything is a tradeoff rather than having an absolute answer.

[0] https://news.ycombinator.com/item?id=29792859

>For example, A/B testing, anomaly detection and merge queues.

A/B testing is arguable a product based thing. It can be called "engineering" but it's not strictly a software thing. It's associated more with UI.

I've never seen anomaly detection used with software development. Looks more like a data ML thing.

Merge Queues are just a collaborative tool. I mean you can use this on any document outside of software engineering. Say, for example, CAD drawings where a bunch of people work collaboratively.

I don't think your examples are focused enough to be strictly things that are part of "Software Engineering" in the same way agile isn't strictly "Software Engineering."

>Software processes are designed with mathematical/statistical backing when needed.

This is rarely done. Very little statistical methods make it into the dev process or are even influenced by the dev process. When it does make it in there's no common methodology either as it's usually just some data driven behavioral changes based off of some analytics. The reasoning behind why it's like this is clear. At it's core software is deterministic. Code is simply a series axioms and theorems that can be logically proven correct. Statistics is for unknown processes and is usually employed at the intersection of software and real world stuff like the failure rate of ssd drives.

A passing unit test does give more confidence that a program is correct. This is a statistical phenomenon, but hardly anyone tries to actualize it from a statistical quantitative standpoint.

>does it work and is it cheap? In software, both of these are usually non-issues so things can vary a lot more.

I disagree. These are issues and we do use methods to mitigate these things. We want our software to work and we want to build it at a certain cost. Agile and measuring velocity is a way to monitor costs and working software is verified through mostly testing.

But most of this stuff isn't engineering. It's done out of necessity. There's no mathematical modelling going on as it's hard to even quantify the costs of software or even correctness. Hence why it's all arbitrary processes made up by managers.

>I suspect you will call this arbitrary, but I see these process decisions as conscious choices. The fact these aren't grounded in mathematics or statistics is not a big deal to me because the goals/focus are more complex than does it work and how much does it cost.

All decisions made in any field even say plumbing is a conscious choice. The difference is in engineering we use science and mathematics as much as possible to optimize these choices. We don't in software. Mainly because it's hard to model it.

>In software everything is a tradeoff rather than having an absolute answer.

Everything in life is a tradeoff. It's like this in fields OUTSIDE of engineering as well. The thing with engineering is you try to optimize your choice using math and science as much as possible. In software no such optimization procedure exists.

That is not what I meant by a Merge Queue, this is: https://news.ycombinator.com/item?id=21584144.

> The thing with engineering is you try to optimize your choice using math and science as much as possible. In software no such optimization procedure exists.

It's comparatively easy to optimize something with an absolute answer. Ex: will this building fall down with x design?

It's practically impossible to optimize something like: will our software development process allow us to deliver new functionality faster and win market share?

There is far more ambiguity in software development than in other fields.

https://en.wikipedia.org/wiki/Software_engineering#Definitio...

https://en.wikipedia.org/wiki/Software_engineering#Criticism

>That is not what I meant by a Merge Queue,

I meant exactly what you're referring to. Source code isn't the only thing that can go under source control. As long as the file isn't fully binary and is in a somewhat readable human format it can be subject to version control and therefore a Merge Queue.

>It's practically impossible to optimize something like: will our software development process allow us to deliver new functionality faster and win market share?

This is my point. It's impossible in the same way optimizing a painting of still life is impossible. Therefore it's not really engineering.

>There is far more ambiguity in software development than in other fields.

Edsger Dijkstra, had it right.

"What we do is a craft."

Nobody except you cares about your craft though.

They care if you can accomplish the things they need accomplished.

If your craft is 'building quality decks' - and they want a 'quality deck' - then great.

But if your craft is 'building byzantine window structures with 4 plane glass imported from Italy', well then, it's going to be hard to work on a house if that's all you care about.

Software Development is a skilled trade, it's more like Carpentry than it is academic, it just has some elements that can be very academic.

What we do is a craft.

But it's an extremely narrow slice of this "craft". Right?

Where is this generation's "Moving Mount Fuji" that explains the history of leetcode puzzles and their ineffectiveness? https://m.slashdot.org/story/34239

Moving Mount Fuji

I see someone at microsoft was a fan of The Shamen.

https://www.youtube.com/watch?v=SpjnzxtZ6Qg

The video is unavailable.

https://www.youtube.com/watch?v=bfQ98A-6mG8 should be available for US users

I wonder that as well. I don't see any significant connection between Leetcode or Leetcode-style questions and anything resembling what a company theoretically should be looking for in an engineer. The only thing I can come up with is that being able to memorize or otherwise internalize so many different problems is a proxy for intelligence (general mental ability). If so, I suspect it's a fairly weak proxy.

But, is that it? In the US, at least, not a lot of employers will give a straight up test of general mental ability (IQ test), likely because they see it as potentially attracting lawsuits. This is because IQ tests show a well-documented racial disparity in scores, which has not been shown to be correlated with anything genetic. Rather, the problem is either traced back to differences in family socioeconomic status growing up, or cultural bias issues with the tests.

Everything in the previous paragraph can be verified in a few minutes of Googling, so, I'm not going to litter this comment with citations when the obvious keywords will produce the information mentioned here. But, everything else, including what's to follow this, should be considered pure speculation on my part.

Given all this context, I can only think of 2 obvious reasons companies resort to using LC or LC-style interviews:

1. As a proxy for a test of general mental ability, as previously mentioned, or

2. Cargo culting, as with the whole "How would you move Mt. Fuji?" phenomenon.

I don't personally have a great deal of insight into which it is, or, if there's a third explanation that I'm completely missing. I also don't know whether there's any research supporting or refuting the idea that LC puzzles provide a valid interview signal for software engineers. All I really know is that these type of problems exercise skills that are not what one uses on the job as a SWE, so, it seems rather illogical to use them as a main component of your hiring process.

It's a weak proxy for general mental ability, but it's also a signal for high conscientiousness -- someone willing to spend a couple months studying to the test is showing that they have the ability to work hard on something over some length of time.

Why not bring back the civil service exams of Imperial China, then? Surely one's willingness to undertake extended study of the classics of Chinese literature, and to master a stylized form of discourse about them is also a signal of conscientiousness, isn't it? As a "bonus," this is likely to take far longer than the few months people spend practicing Leetcode.

https://en.wikipedia.org/wiki/Imperial_examination

https://en.wikipedia.org/wiki/Eight-legged_essay

When I was in grad school for CS, I recall talking to the dean of the department who said that his preferred approach for recruiting CS students would be to have them write a five page essay on any topic of their choice. Anyone who could write a coherent essay would probably make a good researcher. Unfortunately, he was never able to put this into practice - the university administration only considered grades and GRE scores.

I thought my ability to build a prototype in a day showed that. Maybe I should have learned every variation of FizzBuzz instead of learning how node works.

Does grinding for months even work? The point of this post (and others like it) is that you can spend years doing leetcode without getting better. In comparison, I score far below most of my peers on conscientiousness but I find leetcode style problems easy. I'm a terrible hire in lots of roles because most companies' problems are boring. I have a history of getting bored and quitting. But I sail through these interviews.

If conscientiousness is what companies are going for, I think they're still interviewing wrong.

I think it works to some extent. There's a limit to how much you can get out of yourself, and a lot of dumb luck involved in getting interviewers who are actually reasonable.

In my case, when I grind those dumb problems I quickly go from needing 45+ minutes to implement a working sort function with file I/o to banging it out in 5-10 minutes. I dunno if I'd ever get good enough at those problems to make it into Google unless I got lucky, but I've gotten offers from the other FAANGs over the years

The whole thing is pointless, though. If a junior engineer asked me for advice, I'd tell him to get whatever job he can and work on saving money/building a startup in his spare time.

Grinding for months to get into Google is so soul crushing, and working for any big company is just awful in the long run compared to being independent

I think leetcode is just like anything else you practice - in order to actually improve you need to practice the right way (or in the OP's case, with the right state of mind! Being burnt out is a fundamental problem which needs to be fixed first!)

I started out thinking I was pretty smart but got blasted by a fairly simple question on my first screening interview. I started looking at random leetcode questions but that didn't really work - I soon figured out that I needed to learn the concepts one at a time. I think that is the way to do it, get a list of general topics, learn about it, then practice just those questions until it clicks.

It's also a weak proxy for high conscientiousness. More often than not, it's actually signalling someone is young enough to not have other commitments, contributing to age discrimination without even meaning to. It also does in the way that older engineers are less likely to have CS degrees just because CS programs were rarer and less well-known before the 90s.

That's not sour grapes, either. I have a CS degree and worked through math and logic puzzles for fun from the time I was 6, well before I ever knew what a computer was. Interviews like this are practically made for someone like me, but even there, the signal you're getting is I'll gladly do something I like doing anyway, not that I'm going to show similar conscientiousness when it comes time to get into your daily company grind that actually has nothing to do with solving interesting algorithms puzzles.

I'd say it's a signal for a rather mediocre kind of conscientiousness -- that is, for someone willing to put in long hours to achieve a certain goal, for sure -- but for a goal they almost certainly believe to be fundamentally pointless.

And as such, is likely to cause them to develop cynical attitudes about the industry -- and about the companies requiring these tests, in particular.

Due to a series of coincidences I've worked at 3 companies in the hiring space in my career, and I've personally performed over 400 tech interviews. I've also spent 2+ years teaching programming. I feel like I can answer that question - though I'm sure plenty of my colleagues would disagree with my answer.

Essentially I agree with you - most of the reason is cargo culting Google.

Assessing software engineers is hard. A couple decades ago, Google (which at the time was a tech darling, and the #1 place to work) had a saying of "A players hire A players. B players hire C players". Essentially they were terrified of hiring bad people, because they figured the company would inevitably go downhill if they did. Their hiring process was essentially an expression of this idea - it was based on the philosophy of "we're all A players, but are you as clever as us?". Interviewing at google at the time involved sitting about 6 back to back whiteboard interviews with programmers. Each person would spend ~20 minutes asking you their favorite puzzles and things, and seeing how you did. Nobody can say this because it would be illegal, but it was in many ways a programming themed IQ test. Good questions were the ones which filtered candidates out. And its easy to recommend against hiring someone if they couldn't reverse a binary tree on a whiteboard in 20 minutes. (I mean, thats easy for me! They must be a C player.)

Other companies followed suit. I mean, hiring is hard. Why not just copy Google's approach? Microsoft did something similar. Facebook was full of ex-googlers, etc etc.

The problem is that being able to reverse binary trees doesn't correlate with how well you can manage a database, style a form, fix a memory leak or talk to your team. And the people who only had those useful skills are unhireable. Oops!

In my opinion, the right way to interview programmers is to make a list of skills you want your programmers to have (coding, debugging, CS knowledge, communication skills, architecture, ...) and then find ways to assess each one. For example, to assess debugging you can give your candidate some pre-prepared code with failing test cases and see how many bugs they can fix within 30 minutes or so. But that requires preparation and test calibration. Most companies struggle to convince their engineers to interview someone for 20 minutes - let alone spend a few days putting together a problem like that.

Knowledge of data structures and algorithms is useful, and it is a positive signal about a candidate. But (depending on the role) I'd weight it below communication skills, raw coding skill and debugging. Those are all much more valuable. We need to start treating them as such.

Funny thing is that A players can go downhill not because of their engineers, but because of their management. How many companies have we seen in tech go under because of bad engineering vs bad management?

>Essentially they were terrified of hiring bad people, because they figured the company would inevitably go downhill if they did.

I heard that Google search is now performing badly in many key areas.

Yet one should be very skeptical about such claims. We don't know the parameters what they are optimizing for so how can we even asses it's performance related to those?

It is indeed, by my own subjective observation.

But that doesn't mean it's the fault of the engineers - and most likely it isn't.

Rather, the product people (who are also not dummies) basically realized that "dumber" results were more profitable, for various reasons -- most likely to do with "engagement" and prioritizing what 90 percent of the users will versus the needs of the other 10 percent.

> For example, to assess debugging you can give your candidate some pre-prepared code with failing test cases and see how many bugs they can fix within 30 minutes or so. But that requires preparation and test calibration.

The tricky thing is that no matter what test you contrive, it's more likely to say something about the developer's recent experience than about their competency in general.

For example, I'd say I have pretty good intuition for when to just read code or sprinkle printfs or fire up valgrind/gdb/asan when debugging C. Which I guess is to be expected given that I've been doing C almost exclusively for many many years. I'd do pretty bad with Haskell; the last time I really used it was around 13 years ago. The next guy might be a bit lost with gcc's error messages since the last time they used C in anger was 5+ years ago for a small project, but they'd do well if you hand them Python code that uses a well known unit test framework or whatever. I guess that's fine if you're a run of the mill crud company looking for "senior <foo-language> developer" but not if you're after general competency.

You can try hard to make the debugging be more about the system than about the implementation but it's not easy to separate the two. You can make different tests for people with different backgrounds but that only makes calibration harder.

One trick I've seen a company do is deliberately pick a very obscure language that most people have never heard of. That can eliminate some variables but not all of them (I took the test and did well but I also spent a fair amount of time studying the language to figure out if it's suitable for a purely functional solution before handing in a very boring piece of imperative code). Ultimately it wasn't much more than a fizzbuzz.

And if there's puzzling involved, I'd say there's an element of luck involved. At least that's how I perceive the subconscious mind to work when you're thinking about a problem that isn't immediately obvious or known to you beforehand. Which path does your mind set you on? Are you stupid or incompetent if it happened to pick the wrong one today and you spent 10 minutes thinking about it too hard? Are you super smart if the first thing that came to mind just happened to be the right one and you didn't doubt yourself before blurting out an answer?

If you're lucky and know the problem beforehand, you can always fake brilliance: https://news.ycombinator.com/item?id=17106291

That is to say, test calibration is hard and there are so many variables involved. It follows that there's no obvious right way to conduct interviews. And I guess it follows that companies who need people (and aren't necessarily experts at interviewing) effectively outsource the problem by conducting the same type of interviews they've seen elsewhere. Maybe that's less cargo culting and more just doing whatever seems popular and good enough?

The best solution I’ve seen to this (if you have the time, and are interviewing for a variety of roles) is to have the same code (& same bugs) in a variety of languages. And let the candidate use their own computer and their own tools to work on the problem. If you’re hiring for a python role, get the candidate to debug python code!

I’ve done hundreds of interviews like this, and it’s fascinating watching what people do. Do they read the code first? Fire up a debugger? Add print statements and binary search by hand? I had one candidate once add more unit tests, to isolate a bug more explicitly.

After hundreds of interviews I still couldn’t tell you which approach is best. But if there’s one trend I noticed it’s that more senior people (& older people) seem to do better at this assessment. Which is fascinating. And that implies it’s not simply a test of what tools the person is familiar with most recently.

As for luck, I agree this is a problem. It’s mitigated somewhat by having a bunch of easy bugs to fix instead of one hard one. But even a debugging problem like this should be one of a set of assessments you perform. If you fail 5 small assessments in a row it’s probably not luck.

I hate medium and hard LC questions in interviews, it's very hard for me to not get panicky, so I'm surprised i'm going to argue against what you're saying:

If you want to test raw coding ability, asking someone to implement some very basic graph or tree traversals is a pretty good way to see if they know the basics of conditionals, loops, recursions, maybe hashmaps.

If you want to see someone debug something, and you make them run their code it will inevitably fail or not compile the first time...so they'll have to debug.

> If you want to see someone debug something, and you make them run their code

I hear what you’re saying, but that doesn’t assess what I want to assess. We all have experience debugging our own code, that we just wrote. But how well can you read someone else’s code? How well can you find and fix bugs in it? It’s a different skill! And it’s vital in a team setting. Or when you’re depending on complex 3rd party packages (which is most of the time).

I want coworkers who can read the code I write and debug it when it breaks. That’s a much more useful skill than what leetcode problems train.

> This is because IQ tests show a well-documented racial disparity in scores, which has not been shown to be correlated with anything genetic.

That isn't true; the correlation is visible when you look at the scores of people with mixed ancestry.

Same as any profession, the reason for the tests is to sort for compliant employees. Check out the book “Disciplined Minds” by Schmidt.

https://www.bmartin.cc/pubs/01BRrt.html

I would move Mount Fuji by having it situated on an island where like three continental plates meet, and then just kick back and watch. So to speak.

Surely! If what you want is uniform, interchangeable cogwheels for the machine, you check if your candidates can act as uniform, interchangeable cogwheels for the machine.

If everyone is different, how will you decide whom to pick? or filter out. This is why there are standardized tests etc. In our industry it is leetcode, it is a grind, but it is what it is, a standardized filter.

It depends on how your shop is organised. Big corps like interchangeability in their work force, because they wouldn't even know how to allocate their employees as individuals. Smaller shops are better able to exploit specific skill profiles and may even tailor some business decisions to make the best use of their specific strengths.

If everyone is different, how will you decide whom to pick?

Remember those "thinking outside the box" skills we're supposed to have?

This is what we need to start using them on.

> Tried architectures/patterns are what is expected.

Don't forget that software engineering is often up to 100 people team sport. If every repo and every algorithm has a special snowflake unique flair put upon it, then you have to relearn everything each time you open someone else's repo... also you cannot directly hire for the work, instead you have to hire smart people who start nearly at zero to rapidly learn the nuance of each repo they work on. This is a young man's[2] game (before intelligence crystalizes and energy levels wane)

If there is a good amount of run of the mill computerscience/eng then you can hire people who can start fast(er) and they can build off assumption rather than on having a bunch of special code precariously "cached" in their working memory.

[1]: I'm speaking in generalities, yes some young people are tired/fixed mindset, yes some older people are energetic/flexible -- but afaik the psychology/science bears this difference out

Reply on news.ycombinator.com