| ▲ | MrMcCall 2 days ago |
| Our final CS course, Operating Systems, was in C, after all the previous courses were in Pascal. Luckily, I had already gotten access to various Unix systems and had taught myself C (thanks, K&R !!). And I say luckily because it was expecially lucky for my SWE group members who would otherwise have not graduated. I was already 10x at that point because of early access and passion for the craft. Most if not all of them had already decided that programming was not their career path, so it was in everyone's benefit and happiness. Funny enough, there was no version control at our uni (a pretty good one, but not primarily technical), and that OS we tweaked for the course was the current version of Tanenbaum's Minix that Linus transformed into Linux. 20 minutes for a recompile and test loop to fix that stupid mistake in the semaphore logic was painful, but that's life on a 286. It took real passion to want to bang through that learning curve. It really weeded out the folks who were just looking for an engineering job, at least for the handful (4) of people I knew in the program. |
|
| ▲ | aleph_minus_one 2 days ago | parent | next [-] |
| > It really weeded out the folks who were just looking for an engineering job Wanting an engineering job means that engineering is such an important part of your life that you desire that your job (i.e. many hours each day) centers around it. The breed of people that you mentioned to be weeded out were not looking for an engineering job, but for some well-paid (often management) job that formally requires engineering qualifications, but where the daily business has barely to do anything related to engineering. |
| |
| ▲ | MrMcCall 2 days ago | parent [-] | | In this ~40yo case, I'm guessing it was more of a "I got into a very prestigious state university because I busted my butt in high school and I've learned that CS is a high growth industry." The talented and hard working folks got in and found that studying algorithms at the beginning of the 3rd year from a textbook was doable, but designing and implementing a significant software system (or tweaking an operating system) in the 4th year is a whole other level. It's just that software design and engineering is really a unique beast. I mean, it is the most difficult engineering on the planet, because every single other industry and discipline depends upon it. | | |
| ▲ | ninkendo 2 days ago | parent [-] | | It certainly should be the most difficult engineering on the planet, yes… but IME the standards for quality are so low that it’s a pretty easy gig. You’re expected to slap together stuff that barely works and fix things later. That’s now how any other engineering discipline works, or at least not nearly to the same degree. Also it’s hard to observe how hacky software is from the outside, so it’s easy to get away with a terrible mess of code that would nauseate anyone who looked at it. Most of the time management doesn’t even care. Watching Practical Engineering on YouTube is a pretty illuminating experience for me as it as it shows the extreme care that goes into projects from the outset, how much planning is involved, how much we’ve learned from centuries of experience building things, and how even despite all of this, things can still fail spectacularly. And when it does, there are independent reports done by thorough investigators, who find the real root causes and carry the knowledge forward for future projects. It makes me sad that Software isn’t treated this way. Yes, we get things off the ground fast, but we don’t learn from our mistakes, we don’t conduct thorough investigations into failures, and often people just release things and move on to the next job. Software may be a more complicated and “difficult” discipline but it sure isn’t treated like it. | | |
| ▲ | MrMcCall 2 days ago | parent | next [-] | | Its difficulty and uniqueness is why it just hasn't been 'engineerized' or 'engineerified' yet. It's still a craft, as opposed to an engineering discipline. As such, that means the quality of the software produced by any shop is going to vary according to the organization's standards, which is their combination of management and engineers. Sometimes management is very business-schooly in their perspective, sometimes more engineery. That boundary layer and how it is treated by the top of the hierarchy makes all the difference. I was summer programming in an IT department in the late 80's; it was under the auspices of the comptroller, simply because the org didn't know where else to put it. Management was still figuring out which department would have the budget/cost stuff allocated to it. You can forget about engineering excellence or even semblance of IT knowledge. Everything since then has been the (in)organic growth of IT in the situation that, for the vast majority of companies, IT is simply a cost whose benefit is hard to quantify, especially to the money guys, who are always the ones in charge. | |
| ▲ | jart 2 days ago | parent | prev [-] | | Planning and "extreme care" makes sense if you're building a bridge. Professional software engineering is more like a demolition derby. If you want to be successful you should focus on building fast and breaking things. It wouldn't make sense to blow up a bridge right after you've constructed it, but with software you can do just that. For example, I was just using American Fuzzy Lop a moment ago to break my symbol demangler. It was able to find eight ways to make it crash in a minute. So I fixed all those and let it run for a couple hours and it found another. Tools like this are a superpower. It's also fun to write torture tests and DDOS your own infrastructure. If you don't break it then someone else will. |
|
|
|
|
| ▲ | jart 2 days ago | parent | prev [-] |
| With that kind of build latency, you're weeding out people who don't want to spend their whole day on coffee break. |
| |
| ▲ | MrMcCall a day ago | parent [-] | | Yeah, I guess. I rather enjoyed those days but was always craving more power to just get on with it. And those build times were nothing compared to waiting for a long SQL process. It's all really just determining whether the data flowed properly or not. From a C64 BASIC program to an OS component to a database's tables, it's all just data flowing from one place/form to another. |
|