Earlier quoted context omitted.
even implementing all of sql92 or datalog without concern for efficiency is fairly complex
implementing a toy datalog should take no more than a week.
maybe less
Challenging projects every programmer should try (2019)
291–300 of 346 posts
Re: Challenging projects every programmer should try (2019)
#292All of these are fairly easy to make in languages like Scratch but hard to make in lower-level ones. I don't know enough about coding theory and such to understand why, though.
The only one of these that Scratch might make easier is the Space Invaders game
Re: Challenging projects every programmer should try (2019)
#293Earlier quoted context omitted.
Notice it said programmer , not software engineer . Speaking for myself, software engineering is something I do because I have bills to pay. Programming is something I started doing because it’s fun. The projects in this article are the types of projects I would do for fun if I had the time.
> Software engineering is something I do because I have bills to pay. Programming is something I started doing because it’s fun. Sudden clarity. I feel like printing it and putting it next to my workstation, so that I remember this both when doing something fun and when having to work so that my bills get paid.
Yeah, this is a very important realization to make in a career of a software engineer.
Other points to internalize:
- in business, software is made to either earn money or pay less money. All other effects are at best secondary
- code is a liability as much (or more) as it is an asset
- programming is the easy 0-20% of the job of the software engineer, the rest is making sure the right thing gets programmed
- no matter what they tell you it’s a people problem
- software is always broken but it keeps running as long as practitioners are keeping it within the operational envelope
Re: Challenging projects every programmer should try (2019)
#294Earlier quoted context omitted.
>Not all hackers are overly obsessed with the most efficient Big O and various low level (sorry pun intended) details. A NAND gate is low level. Big O is just theory that anyone should know if he's worth something as a programmer.
Most of the time, big O is not relevant if you're not writing new algorithm. For the usual CRUD app? Not so much. Heck even for more involved work, you will not touch them because your solution will be called or will call some external tools. The good news is that, while still valuable, you won't have to lose time creating a new broken wheel. The bad news is that this part of CompSci is now mostly fundamental researc…
It becomes very important as soon as you start getting statement timeouts in your db queries.
Re: Challenging projects every programmer should try (2019)
#295Earlier quoted context omitted.
> This is like telling a student learning an instrument never to practice scales or études No, it's like recognizing that an orchestra conductor doesn't need to play every instrument (or even any instrument!) in order to make music. Or alternatively, that a violin player doesn't need to understand the physics of acoustic dispersion in order to be the best in the world at playing the violin.
Yes a software engineer understanding data structures and runtime complexity is akin to a violin player understanding the physics of acoustic dispersion.
So here’s the thing… I did an EE/CS dual degree. I’m going to focus on the EE side of it for a bit.
We learn the high level practical behaviour of devices: resistors, capacitors, BJT and MOSFET transistors, opamps, logic gates, etc in 2nd year. What we learn there is enough to be an effective practical circuit designer.
We also dive deep into how that stuff works under the hood. One course I remember fondly started the first lecture with “This course is called semiconductor physics. To understand semiconductor physics you need to understand solid state physics. To understand solid state physics, you need to understand quantum mechanics. We have a lot of material to cover so let’s get started.” A similar course was Electric and Magnetic Fields, where we spent a ton of time applying vector calculus to situations of varying complexity to get a better understanding of how the things we learned in 2nd year actually work and some of the limitations that you wouldn’t pick up on from the practical (generally first-order) models.
You don’t get to graduate with an EE degree without learning this stuff. And in my mind, that stuff is like a mixture of data structures, runtime complexity, assembler, and cache coherency. Fundamental understanding that while you won’t use directly in your day-to-day work but underpins everything you do.
Re: Challenging projects every programmer should try (2019)
#296Earlier quoted context omitted.
Yes a software engineer understanding data structures and runtime complexity is akin to a violin player understanding the physics of acoustic dispersion.
So here’s the thing… I did an EE/CS dual degree. I’m going to focus on the EE side of it for a bit. We learn the high level practical behaviour of devices: resistors, capacitors, BJT and MOSFET transistors, opamps, logic gates, etc in 2nd year. What we learn there is enough to be an effective practical circuit designer. We also dive deep into how that stuff works under the hood. One course I remember fondly started t…
The job market for EEs...still isn't as hot as for CS people. However, you could also focus on DSPs in EE and use it to get a heads up on machine learning. This assumes you are ready to specialize, however. Anyways, none of it should go to waste.
Re: Challenging projects every programmer should try (2019)
#297Earlier quoted context omitted.
I'm not sure what you mean. Sounds a bit like you might be misunderstanding what were talking about.
It is a bit rude to become confused and then assume the other person was the one with the misunderstanding.
I'm just curious about what you're talking about. Tolerances and physical units are not usually mentioned in relation to time/space complexity. I'm open to the idea that you may know something I don't, feel free to enlighten me.
Re: Challenging projects every programmer should try (2019)
#298Doing some 2D game dev without an engine was the most humbling experience that showed me just how ridiculously fast computers have become. You do things that you swear are far too slow to work, and yet it works even on a Game Boy because it’ll do a million operations in a second and a million is apparently a big number. “Wait… so I’m looking up and drawing every sprite every time? There’s no clever diffing happening…
I got my start doing 2D games on the TRS80 color computer and it really gave me a good foundational understanding of computers. Because it was just bare hardware and assembly, you had to do everything manually, graphics, sound, input, memory mgmt, etc.
I think an ideal intro for programming would be if there was an environment where a new programmer could handle all of these things to create a 2D game, but in a simplified way, so they could get the idea without having too much excess baggage just to make it work.
Re: Challenging projects every programmer should try (2019)
#299I feel the profession has layers. I had a dream in which I had a seat next to Bill Gates on a commercial flight (bear with me!). I asked him how he pursued software development now that he was running the world’s largest software company, and he said, by running the world’s largest software company. Of course that wasn’t necessarily his actual opinion, more like my own brain laundering my own opinion.
Re: Challenging projects every programmer should try (2019)
#300Earlier quoted context omitted.
So here’s the thing… I did an EE/CS dual degree. I’m going to focus on the EE side of it for a bit. We learn the high level practical behaviour of devices: resistors, capacitors, BJT and MOSFET transistors, opamps, logic gates, etc in 2nd year. What we learn there is enough to be an effective practical circuit designer. We also dive deep into how that stuff works under the hood. One course I remember fondly started t…
The job market for EEs...still isn't as hot as for CS people. However, you could also focus on DSPs in EE and use it to get a heads up on machine learning. This assumes you are ready to specialize, however. Anyways, none of it should go to waste.
I’m quite a ways into my career and being able to dance up and down the “full stack” from designing circuit boards, to writing low level firmware, to backends in Python/Elixir/Java/etc, to frontends in JS/ObjC/Kotlin/Swift/Dart has been a lot of fun. I did the dual EE/CS degree because the “computer engineering” program wasn’t introduced until a few years after I graduated.
That’s all kind of missing the point though. This whole thread has been a discussion about whether Software Engineers need to get down into the nitty gritty low-level stuff. My take is absolutely yes. You might not use it directly every day, but you’ll make consistently better design decisions if you really feel it in your bones. Over on the electrical engineering side of the world you don’t get to graduate without that background understanding. In the software engineering world some people seem to take pride in their ignorance of the foundations they’re building in; in my 20-ish years of experience, those people often end up building things that work poorly and they don’t have the background understanding needed to fix it.