Yeah, computer science is the more about theoretical side of computation and the analysis of algorithms. For example, proving that a certain algorithm is a solution to a problem and has a particular time complexity. That’s more mathematics than practical programming.
I’ve haven’t had a burnout (knocks wood), but the most toxic environment I’ve worked in had tight deadlines, unclear requirements and many last minute changes on features that ultimately didn’t mattered. Combine this with long and tedious release processes and narrow release windows. If a bug slipped through our (not so robust) testing process, it was difficult to fix it.
It felt like the priorities were all wrong. Instead of improving the product for existing customers and improve our release process, it was all about adding pointless features some ”potential buyer” asked for (they never bought the product either way).
Now I work in a much better workplace, thankfully.
It’s just example code to demonstrate the idea of the optimization explained in the article. I also based my code on the code used in the article (and made some major changes to better fit my attempt of explanation).
Basically it’s just an optimization of a double nested for loop. It’s a way to avoid running the inner for loop when it is known there will be no hit.
This is useful when we for example want to find all product orders of customers in a particular country. The way we can do this is to first filter all customers by their country, and then match orders by the remaining customers. The matching step is the double for loop.
Something like this:
for order in orders:
for customer in customers_in_country:
if order.customer_id == customer.id:
…
Many orders won’t match a customer in the above query, so we want to single out these orders before we run the expensive inner for loop. The way they do it is to create a cache using a Bloom filter. I’d recommend looking it up, but it’s a probabilistic cache that’s fast and space efficient, at the cost of letting through some false positives. With this particular use case it’s ok to have some false positives. The worst thing that can happen is that the inner for loop is run more times than necessary.
The final code is something like this:
bloom_filter = create_bloom(customers_in_country)
for order in orders:
if bloom_filter.contains(order.customer_id):
for customer in customers_in_country:
if order.customer_id == customer.id:
…
Edit: this comment probably contain many inaccuracies, as I’ve never done this kind of stuff in practice, so don’t rely too much on it.
I hate when coworkers tell we should do thing in a particular way because it’s ”better”. We try the thing and there’s no measurable difference. Well, it was a good idea in their mind, so it must be an improvement. Therefore, they insist it should be kept, even if it makes the code extra convoluted for no reason at all.
And yes. Profiling is great. Often it is a surprise where most time is spent. Today there’s few excuses not to profile since most IDEs have good enough profiler included.
Nice article. For the optimization related ones there’s a good rule of thumb: it’s not an optimization if you don’t measure an improvement.
That’s how DRY is described in Pragmatic Programmer, where DRY was first coined. They’re clear that just because code look similar, doesn’t necessarily mean it’s the same.
I agree with the first point. Always go for clarity over cleverness.
I somewhat disagree with the second point. Consistency is important. Stick with the same name when possible. But I think mixing camel case and snake case should be avoided. It can make the code less ”greppable” IMO, because now you need to remember which casing was used for each variable.
Kind of agree on the third point. I think flatness should be preferred when possible and when it makes sense. Easier to find the variables with the eyes rather than having to search through nested structures.
I’m at the point where I think I can engineer anything. But I also know that it takes effort and I ain’t gonna do that unless there’s a paycheck.
Java with Spark.
Although I feel like I’m doing less of data science and more of data processing.
I still haven’t grown out of my ctrl + alt + del habit
I don’t really know how to describe him. I guess Casey is proof that one can be skilled in programming, but still have a fundamental lack of understanding in software engineering.
This is just so wrong. He’s too nostalgic of the Amiga days.
First, he has no concrete proof that many lines of code is bad. He’s just saying “I feel like things are worse now and here’s a graph that correlates with my feelings”.
And then he shows a graph of the number of lines in the Linux kernel. Yeah, Linux grew in size mid 90s because that was when people wanted to make it work on computers other than Torvald’s own!
Secondly, no one wants to plug in an USB and grant whatever is in it full machine access. It’s a major security concern, and people want multitasking. What if I want to listen to Spotify while I play my game?
The USB thing is likely not going to work either way because it can’t take into account for all possible configurations. Too bad, this program doesn’t recognize your specific WiFi card. You have to survive without internet.
Unless someone manages to perfectly standardize everything that can possibly happen in a computer. That ain’t going to happen.
You’re a big function
Math skills can occasionally be useful, but I don’t see it as a dealbreaker.
The good thing about being good with math is that it usually means you’re a good problem solver, and problem solving is an important skill for programming. But the reverse isn’t necessarily true. You can be good at problem solving but still be bad at math.
I would say if you’re struggling with the programming courses, then maybe look somewhere else. Otherwise, go ahead.
They would see nothing wrong with it
Python is truly a mess when Docker is considered a solution.
Nothing comes close to Perl’s abuse of global variables. Oh you called this function? Take a guess which global variables it will use.
Writing maintainable code is an art form. Like most art forms it can mostly only be learned by practice. So if you don’t have much experience maintaining long lived systems, it’s difficult to know what works and what doesn’t. Most universities don’t teach this as well, so it’s mostly something people learn in the industry.
Then I believe there’s also some aspect of pride in writing overly complicated code. It’s the belief that ”other people can’t comprehend my code because they’re not as smart as me”, when it’s actually ”I suck at writing comprehensible code”.