New Grad vs. Senior Dev - <AUTHOR> https://ericlippert.com/2020/03/27/new-grad-vs-senior-dev/ <comment><USER2> I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3."

That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and readability improvements (f-strings) in 3. I can get the test/refactor done in a month, and I think it's a net positive." They were right, and now we're on python3.

So, sometimes we all learn something.

<comment><USER3> The reverse of this also happens: new team manager joins a team of 4-5 dev and goes "eww... a monolith, we'll write an MVP in 3 weeks with microservices, CQRS and all".

Long story short, one year and a half passes and the mvp is still not finished, the architect leaves the company and some poor guys (from an outsourcing company) are still going at it with the same architecture.

<comment><USER4> CQRS and microservices has so much overhead, I'm amazed at how many companies adopt microservices without having anyone know a single thing about distributed systems. I think people underestimate the glue required to make microservices be useful. I had a similar situation at my last company where they spent a year and a half converting their monolith into half ass microservices and it still wasn't working properly. They also stopped releasing new features on their product during this entire conversion which obviously lead to a drop in customers. The mass exodus of employees at the end was something beautiful though.

<comment><USER5> I would argue that main reason for adaptation of microservices is to actually prolong development time (moar dollars) and make devops as convoluted as possible to safeguard data. Or foolishness.

<comment><USER6> I don't understand the hate for microservices on hn. I have found microservices are a great way to extend monoliths developed with legacy frameworks. There are so many pros with the cons easily avoidable with the right tooling / processes.

<comment><USER7> Basically it comes down to

Distributed logging:hard

Distributed debugging: hard

Distributed versioning: hard

Distributed transactions: very hard

And on 95% of projects these problems aren't worth solving for the benefits of microservices.

<comment><USER3> > And on 95% of projects these problems aren't worth solving for the benefits > of microservices.

And especially with a team of 4 or 5 developers.

<comment><USER8> I just started working on a new project about half a year ago, completely greenfield. The backend developer (there is only one...) jumped into microservices directly, deploying on AWS Fargate, trying to split out as many things into containers as possible, because that's the "proper" way of doing it. We still have few users as the project is new, but hey, at least we could scale to 100000s users in a few minutes, instead of having easier logging, debugging and versioning

A lot of stuff in software engineering is just driven by what's popular, not what's needed.

<comment><USER9> A monolith can handle millions of daily unique users. The database is the hard part.

In the web world, if you have less than 10s of millions of daily users, as long as you design an application that holds no state itself, the architecture is usually more important for scaling your team and the size of your codebase rather than the number of users you can handle.

<comment><USER10> With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late.

It's priceless to see their expressions when senior mgmt. and business owners finally find out.

<comment><USER11> > With microservices, you lose the ability to use database transactions across > services/tables. Later on, when people realize this, it's too late.

I don't follow your reasoning. I mean, the ACID vs BASE problem you described is extensively covered in pretty much any microservices 101 course or even MOOC, along other basic microservices tradeoffs such as the distributed tax and ways to mitigate or eliminate these issues like going with bounded contexts. Why do you believe this is a mystery that no one is aware of?

<comment><USER7> I've seen a couple of projects where the original team didn't think they needed transactions, or underestimated how much harder eventually consistent distributed systems are to reason about than an acid system.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I find that the biggest misunderstanding happens because "new grads" (and I happen to be one) confuse _asymptotic complexity_ with actual complexity.

I'm not sure sure why, but CS courses and interview questions mostly focus on _asymptotic complexity_ and usually forget to take into consideration the complexity for "little values of n". And funnily enough, in real life n never goes to infinity!

In a strict sense big O notation only cares about what happens when n goes to infinity. The algorithm could behave in any way up to numbers unimaginable (like TREE(3)) but still, its big O wouldn't change.

Maybe what is missing to those "new grad" is a felling of real world data, and how a computer behave in the real world (with caches, latencies, optimised instructions etc...) not just having an ideal computer model in their mind when they design algorithms.

<comment><USER13> It's because Big O is Computer Science. Cache effects are Software Engineering. Professors of CS do a fine job of teaching CS. They even briefly mention that there is a implicit constant factor k in O(k n log(n)) and then they never mention it again. They certainly don't mention that k can easily vary by 128x between algos. AKA: 7 levels of a binary tree. Or that most of the data they will be dealing with in practice not only won't be infinite, but will actually be less than 128 bytes. Or, that even with huge data and an proven-ideal O() algo, there is often 10x speed-up to be had with a hybrid algo like a b-tree instead of a binary tree. And, another 2-10x with SIMD vs scalar. 100x isn't infinite, but it's still counts.

So, grads listen to their CS professors and that's what they know. It's not until they get lectures from greybeard software engineers that they learn about the reality algos and not just the idealized algos.

<comment><USER14> > briefly mention that there is a implicit constant factor k in O(k n log(n)) > and then they never mention it again

A fine concrete example of this is the Coppersmith–Winograd algorithm (and its derivatives), a matrix multiplication algorithm with impressive complexity properties, but which in practice _always_ loses to the Strassen algorithm, despite Strassen's inferior complexity. [0][1][2]

(Aside: the Strassen algorithm is pretty mind-bending, but also easily shown. If you've got 22 minutes spare, there's a good explanation of it on YouTube. Perhaps there's a more dense source elsewhere. [3])

> It's not until they get lectures from greybeard software engineers that they > learn about the reality algos and not just the idealized algos.

To mirror what some others are saying here, students should also be taught the realities of cache behaviour, SIMD-friendliness, branch prediction, multi- threaded programming, real-time constraints, hardware acceleration, etc.

[0] [https://en.wikipedia.org/wiki/Coppersmith%E2%80%93Winograd_a...](https://en.wikipedia.org/wiki/Coppersmith%E2%80%93Winograd_algorithm)

[1] [https://en.wikipedia.org/wiki/Strassen_algorithm](https://en.wikipedia.org/wiki/Strassen_algorithm)

[2] [https://en.wikipedia.org/wiki/Computational_complexity_of_ma...](https://en.wikipedia.org/wiki/Computational_complexity_of_mathematical_operations#Matrix_algebra)

[3] [https://www.youtube.com/watch?v=ORrM- aSNZUs](https://www.youtube.com/watch?v=ORrM-aSNZUs)

<comment><USER15> > To mirror what some others are saying here, students should also be taught > the realities of cache behaviour, SIMD-friendliness, branch prediction, > multi-threaded programming, real-time constraints, hardware acceleration, > etc.

Which would have the positive knock-on effect of the textbook being sufficiently obsolete every year or so that the students could no longer trade it in for credit, saving the bookstores money!

More seriously, that knowledge (at least once you attach numbers to it) has a shelf life, and not a very long one. Teaching big-O analysis means the knowledge is timeless, which any good theoretical knowledge is, and moving more towards practice would force the professors to keep on top of the state of the art, and the state of the _mainstream_ , of hardware design in addition to everything else they're doing.

<comment><USER16> > Which would have the positive knock-on effect of the textbook being > sufficiently obsolete every year or so that the students could no longer > trade it in for credit, saving the bookstores money!

That's naive. E.g. SIMD is here since a good time and going to stay. So are GPGPU, with now quite similar architectures for tons of chips.

And Computer Science can actually be about science for real computers, and computers are not 8086 nor PDP11 anymore, and have never been a turing machine. So there actually _is_ some existing generic CS and ongoing research that cares about cache effects and so over. Maybe it is applied CS if you want, and some kind of pure CS should not care about that, but I really don't see what should be the criteria to decide which is what anyway, so IMO there should not be any (but I do _not_ mean that all research should care about e.g. cache effects, just that it is not really useful to attempt to distinguish between those which do and those which don't).

We don't teach advanced math by only showing what was done at e.g. the beginning of algebra. Neither should we stick to _only_ basic subjects in computer science.

</comment></comment></comment></comment></comment><comment><USER17> In real life, you will always start with simple working implementation and go with it. Then if things are slow, you profile your code with a good profiler while running for some kind of real life scenario and spot the slow parts (also keep in mind that profiling may affect the program's behaviour). After that you may want to consider alternatives with less asymptotic complexity iff that's the part causing slowness.

Once I was asked to look for one project to see that if there is any room for improvement to speed up the program. After I profiled the program with the test data, I saw that program was severely affected by a "size" method call on a lock-free concurrent list. Since the data structure is lock free, size method is not a constant time operation and calling it in a large list takes too much time. It was just there to print some kind of statistics, I changed the code so that it is called only necessary not every time some operation occurs. This immediately made program 2-3 times faster.

There were also some parts I changed with some algorithms with less algorithmic complexith to make it faster. Overall, I made the program 6x faster. So sometimes you need to use fancy algorithms, sometimes you just need to change one line of code after profiling.

<comment><USER18> Although I mostly agree, there's certain types of simple, fundamental performance considerations you want to take when writing code the first time, otherwise you're just needlessly dealing with tones of performance issues in prod. Like make sure your DB queries are well covered by indexes, if you're repeatedly looking up items from a list, turn it into a map or set first, in FE code try to keep re-renders to areas of the UI that need updating, etc.

Correctness and simplicity are almost always things you want to focus on over performance, but there's still SOME level of simple performance best practices that you want to stick to up front. Similar to the tradeoff between YAGNI and software architecture - if you don't start with some sort of coherent architecture, your project is gonna descend into a spaghetti mess. Ignore simple performance best practices and you'll spend way too much time fighting performance issues.

<comment><USER19> > Correctness and simplicity are almost always things you want to focus on > over performance

Right, it's a balance good developers know how to tread. Obviously if you can use a set instead of a list and it's one line change, go for it. But as the meme in OPs post, if you're gonna USE SEGMENT TREES and all, then it better be worth the amount of complexity and time you're putting into it.

Part of what makes a good engineer is being able to quickly tell where it's worth optimizing and where it isn't. Or as the meme says, when nested loop goes BRRRRRR.

<comment><USER18> Yeah agreed with all of that.

</comment></comment></comment></comment><comment><USER20> By the way, here's an anecdote for the flip side: at one of my internships I was working on a tool to process large log files, and by careful application of Aho-Corasick I was able to make it about _50 times_ faster on the dataset we were dealing with, which made using the tool change from "let's go grab lunch while this finishes" to "let's stream the logs through this live". Sometimes you do know how to make things faster: just make sure to test them before you do, and asking why something is a certain way is always a good thing to do before proclaiming it's broken.

<comment><USER21> For interest's sake, did you try simply using a decent regex engine as an alternative? Any DFA regex engine implicitly implements Aho-Corasick for you.

<comment><USER20> I think the engineer before me put a bit of effort into this, but it didn't work out all that well in this case. This isn't surprising considering that the standard regex tool on the platform wasn't known for being particularly performant.

</comment></comment></comment><comment><USER22> Heh... reminds me of my first proper MS internship, when I too was responsible for speeding up some code, this time in the VS Code Go extension. This code was responsible for tokenization, so it affected pretty much every operation and ran on every edit. Important shit.

Day 1: do some basic hoisting. O(n^3) => O(n^2). Tokenization times for a 10k line file go from ~15s to 500ms. Sweet.

Days 2-30 [1]: ideate, develop, bug fix, iterate on, etc, a novel (to me) data-structure to speed up the program even more. O(n^2) => O(n x log(n)) (expected). Great! Runtime on 10k line file went from 500ms to _maybe_ 300ms. Oooops.

But hey, all the people working in 500k line files must really love the couple seconds my month of toiling (more importantly, my month of not doing other, more impactful things) saved them.

Learned a lot from that experience, and writing this out now I can see how that impacted engineering decisions I make to this day. I suppose thats the _real_ point of an internship, so time well spent, in a way.

[1] It probably wasn't actually a month, but certainly a significant chunk of the internship.

<comment><USER23> > _But hey, all the people working in 500k line files must really love the > couple seconds my month of toiling (more importantly, my month of not doing > other, more impactful things) saved them._

This stuff matters. These couple seconds per operation may very well be a difference between being able to open a 100k+ LOC file in the same editor you're doing your other work in, vs. giving up in frustration and looking for something else that can handle large files. Large files happen surprisingly often (in particular: log files, data dumps, machine-generated code). A "month of toiling" like this may immediately enable new use cases.

<comment><USER22> This is true, but my approach was still not a great one. It turns out the data structure was only accessed in a very specific way, which I could have exploited to dramatically simplify the implementation. If I had researched the problem more before diving into my original idea, I could have achieved the same end goal with much less work.

Lessons upon lessons :)

</comment></comment></comment><comment><USER24> I see these senior vs non-senior engineer contrasts pop up a lot. I'm not a huge fan of them.

It seems that there is a spectrum of skills an engineer could excel at: programming, infrastructure, managing, planning, etc. I've known senior engineers who only excel at a particular skill. I've also known senior engineers who are moderately good at many but not particularly good at one.

In my experience the only difference between a senior and non-senior is that the senior's distribution of skills makes them more effective.

I've also seen senior engineers change roles laterally and become more or less effective, yet still maintain the senior title.

<comment><USER25> Well then, feel free to write your own blog post on a topic you enjoy more!

<comment><USER26> I don't think he dislikes the topic, but rather the way it is framed as senior vs. junior instead of subject matter expert vs. non-expert. The skipto example from your post is not exemplary of the difference between a senior dev and a new grad, it seems very domain-specific.

</comment></comment></comment><comment><USER23> Oh god. That meme.

I've seen it a day or two ago. Can't find the picture anywhere now (I've seen it in some group chat). Anyway, beyond the words quoted at the beginning of this article, the meme's "nested loops go brrr" had a picture of a triple- nested loop using Active Record to do some simple database operations.

To which the correct response is: "it's a 'senior developer' in an industry where you get called a 'senior' after a total of 3 years of experience doing programming; don't do stupid shit like this, _just use SQL like it 's meant to_".

<comment><USER27> Hey, I made that meme.

It was based on a similar story the one in OPs blogpost. At my first job I used to work with some really talented fresh grads that wanted to show off their algorithms skills and ended up over-engineering stuff.

One of them implemented a trie and stored it in SQL lite to implement some string autocomplete where the number of strings was something like 100.

The other implemented a 2D segment tree for doing some grid updates where the size of the grid was small. This inspired the first part of the meme. Segment trees and sqrt decomposition are topics that are popular at programming contests and nowhere else really.

Regarding the triple nested loop, I just wrote the simplest pseudocode that represents nested loops, not necessarily something a "senior" developer would write.

<comment><USER28> New hires showing up at work and doing the one thing they were tested on in the interview. How strange of them!

<comment><USER29> I like to ask interviewees to imitate the sound a computer would make over an AM radio while executing different algorithms.

Nested for loops go brrrrrrrrrrrr, munching squares go bweep bweep bwweeeep bwweeeep bwweeeep bwweeeep bwwwweeeeeeep bwwwweeeeeeep bwwwweeeeeeep bwwwweeeeeeep bweep bweep bweep bweep...

[https://www.youtube.com/watch?v=V4oRHv- Svwc](https://www.youtube.com/watch?v=V4oRHv-Svwc)

Life goes shlup shlup shlup shlup shlup...

[https://www.youtube.com/watch?v=hB78NXH77s4](https://www.youtube.com/watch?v=hB78NXH77s4)

If they use any Don Martin sound effects, I hire them on the spot.

[https://www.madcoversite.com/dmd- alphabetical.html](https://www.madcoversite.com/dmd-alphabetical.html)

>CHK CHK CHA-GONK BRBBRBBRING! -- Man's Eyes Being Poked Like A Cash Registers' Keys And Jaw Popping Open Like A Till Drawer -- Mad #61, Mar 1961, Page 18 -- Kitzel's Department Store

<comment><USER30> Thanks for sharing the DEC PDP videos. I find them fascinating and the sound gives them a new dimension

</comment></comment></comment></comment></comment><comment><USER31> This is a great story. I feel like talented CS students are particularly prone to this sort of myopic thinking; their professors introduce them to functional programming, or the philosophy of UNIX, and they carry that approach everywhere, in a very blunt way. They also carry this little-examined conviction that the world consists of mediocrities and mediocre code and sometimes aren't charitable with the work of others.

<comment><USER32> Putting it another way, knowledge with the bare minimum experience required to be effective is very sharp, and that sharpness is sometimes what's required to cut through old, retrospectively "wrong" ways of doing things. I don't disagree with what you've said, I think we all have met plenty of people fitting your description, I just mean to say there's another side of the coin. As food for thought, much (not all) of the open source software we herald as brilliant today was initially written by people still in or just barely out of grad school.

<comment><USER33> The New Grad had knowledge. The Senior Dev had Understanding.

Understanding > Knowledge

It's that simple.

<comment><USER34> Being pedantic here, but knowledge is equivalent to understanding (information being knowledge without understanding). Wisdom is the word you were looking for (knowledge being wisdom without experience):

The New Grad had knowledge. The Senior Dev had Wisdom.

Wisdom > Knowledge.

<comment><USER33> I see it differently. Knowledge =/= understanding. There are plenty of ppl who know a lot but have little understanding.

Put another way, knowledge is the nodes. Understanding is grasping the connections. Understanding is the higher power. Understanding is where the magic happens.

Wisdom? Wisdom is next level understanding. It's the maturity of developing connection within the connections.

</comment></comment></comment></comment></comment><comment><USER35> I think it's really interesting how complexity theory sort of falls apart in the face of hardware-specifics and concrete use cases. The motto in computer architecture is to make the common case fast (it's in like every textbook), whereas the motto in computer science is to make the program scale/to solve generically. When push comes to shove (as this article shows), the computer architects seem to have the final word, at least when it comes to making things go _more brrrrrr_.

There's so much stress and attention given to complexity theory for software engineers, to the point that people will cram for hours to make it through FAANG interviews. I understand that it's important and it's just something that everyone has to go through... but data structure and algorithm performance is a Wikipedia search away, and then you choose the appropriate STL container and move on with your life. The same can't be said for gaining an understanding of modern processors.

I'm not saying that one is more important than the other or vice-versa, I'm just saying that it seems wrong to me that not knowing algorithms and data structures can break an interview, whereas not knowing hardware is virtually a non-factor.

The big take away for me is this: if you're not benchmarking, you're cargo culting.

<comment><USER36> I think you are wrong. Yes, better understanding of hardware implementation (cache sizes and latency, branch prediction and pipelines, specialized instructions) is important. But also in real life those asymptotic complexities will often have similar c and N_0, or your input will be bigger than N_0, so O(n) vs O(n^2) will still matter. Basic analysis of algorithms makes your life easier because, in this simplified model, you can get a rough estimate of time/space requirements. Of course, if you have competing implementations, you will benchmark them (which is not straightforward to do properly).

By the way, usually we use "complexity theory" for a part of theoretical computer science (math) concerned with proving lower bounds (like the most famous P vs. NP). What is required for basic analysis of algorithms (without any fancy methods) is not very hard. Yes, you can search the web like we all do, but first you need to know what are you searching for. Also, we reuse algorithms/data structures but not only in the final product but also in our own new algorightms so you cannot search it.

Regarding interviews, I think the main problem is that many companies and interviewers try to blindly copy the questions (cargo cult) without understanding the point of such interviews. The point IMO is that you evaluate analytic skills of a candidate. Correct/incorrect answer is not everything. You could do the same with math, science problems but algorithms/data structures are closer to programming. Anyway, I feel this is becoming a controversial topic.

</comment></comment><comment><USER37> Go's strings.Index/bytes.Index also often use the "find first byte" approach; now on amd64 it's a fancy vector instruction. If it finds the first byte too many times without a full match, it falls back to a Rabin-Karp match using a rolling multiplicative hash.

The strings.Index code is at [https://golang.org/src/strings/strings.go?s=25956:25988#L101...](https://golang.org/src/strings/strings.go?s=25956:25988#L1018) and the internal bytealg package with all the CPU intrinsics is at [https://golang.org/src/internal/bytealg/](https://golang.org/src/internal/bytealg/) with index_amd64.{go,s} as the relevant files for x64.

Battle-tested implementations of fundamental things like string searches, sorts, hashtables, allocators, graphics primitives, etc. are often interesting 'cause you find out a lot about what you need (and/or don't need) to work well in practice as well as protect from exploding worst-case scenarios.

<comment><USER38> I sometimes think that you should be be able to hint the compiler that this is a smallish string, this one can be big, this list should be mostly under 1000 elements so that it handles the correct version of an algorithm (bonus point to let me provide several algorithms with different use cases)

</comment></comment><comment><USER39> As a senior dev, I wish that I could say I always knew more than my interns, and that all the code that's there is because it was carefully planned to be that way.

But more often than not, I don't, and it's not.

My take on it is that for the most part senior devs are a lot more paranoid on breaking things and don't want to make code changes unless enough people are asking for it and it'll make a notable difference. Even making things strictly faster can break users if they depend on the algorithm being slow (an extreme edge case that you'd usually say is the user's fault anyway, but could nonetheless be relevant in things like optimizing away a spin-wait).

<comment><USER38> Ah, spacebar cpu overheat [https://xkcd.com/1172/](https://xkcd.com/1172/)

</comment></comment><comment><USER40> Shockingly,

        InStr(<this page of 100+ comments>, "docum") = 0

I'm a dev with some grey hair who feels it would have been useful for all that fantastic domain knowledge from Paterson to get documented in a code comment.

I'd love to hear if either of them ever went back and did that?

<comment><USER25> In this case I think not. However I strongly agree with your position and have tried hard to ensure that my code is commented such that it explains why the code works as it does. See [https://ericlippert.com/2014/09/08/comment- commentary/](https://ericlippert.com/2014/09/08/comment-commentary/) for more thoughts on this subject.

<comment><USER40> Hey Eric thanks for responding here!

Love that article, it was interesting to read your dissection of code comments.

For anyone else reading it, here's an updated link to the CS file referenced in his blog post (the original moved): [https://github.com/dotnet/roslyn/blob/master/src/Compilers/C...](https://github.com/dotnet/roslyn/blob/master/src/Compilers/CSharp/Portable/Binder/Semantics/Conversions/UserDefinedExplicitConversions.cs)

<comment><USER25> Yeah, all the links are wrong now. I'll fix them!

</comment></comment></comment></comment><comment><USER41> I always envy people who work on this level instead of cobbling systems together that integrate several systems all with their own set of flaws and you can be happy if you can make them work together somehow. The algorithm stuff seems pretty simple in comparison. A very local problem that can be profiled well and you can understand most of the factors at play.

<comment><USER23> The "cobbling systems together" stuff is code bureaucracy rather than programming. You're no longer dealing with constraints of physics, mathematics and sound system design - you're building a bit-pushing layer in between Kafkaesque monstrosities that were never truly intended to work together.

Sadly, most programming jobs seem to primarily involve code bureaucracy rather than the "algorithmic" level.

<comment><USER8> I've always seen the "cobbling systems together" stuff as actually software engineering, as that's what you need to have a final production system running. What you describe as "programming" I would say is computer science.

And for me, the work that solves real-world problems tends to be software engineering (using my own definition), rather than computer science (again, using my own definition), which seems to be more about optimizations.

</comment></comment></comment><comment><USER42> This is also why C++ (and hopefully other languages by now) has the short string optimization. On a 64-bit machine, a pointer to a heap-allocated buffer is 8 bytes long. A stupidly large number of the strings used by actual programs are <= 7 bytes long (it's actually more like 20 in C++, because strings also include a length and capacity). Think about it: that's virtually every file extension, path separator, and field delimiter, and a good number of field names, labels, first & last names, usernames, identifiers, URL path components, parameter names, etc. If you can fit the whole string into an immediate value, then you can avoid the heap allocation and deallocation entirely, you can avoid chasing pointers and incurring a cache miss, and you can very significantly reduce the total amount of memory used.

This is also a good reason why, if you're designing a standard library, you really want to have length-prefixed strings instead of null-terminated ones. If you know the length of the strings you're dealing with, you can swap out the algorithm you use, such that you might use brute force for a very small needle, word comparisons if it's exactly 4 bytes long, SSE instructions if it's a word-length multiple, or Boyer-Moore for very long strings.

</comment><comment><USER43> Imagine that the intern didn't dare to ask such questions.

a - he could've gone out thinking that performance doesn't matter. but it certainly does in a piece of code being used daily by thousands of devs.

b - he could've thought that the simple implementation is faster but missed the fact that skip is implemented in assembly.

c - he could've realized both but missed the why.

and these failure scenarios are likely to happen because this is an intern we're speaking about.

One or two tricks up your sleeve do not matter but repeat this a 100 times which one do you think would be a better programmer?

I think the willingness to challenge authority figures and to be (often) proven wrong and to learn from it is an essential part of becoming better.

Maybe Tim was understanding because he himself challenged people older than him and in-process learned form them.

Advice like "don't reinvent the wheel", "avoid premature optimization", "write boring code" promote exploitation. which is the optimal strategy for older agents.

but for newer agents, a higher level of exploration is needed otherwise they would converge into a suboptimal strategy

<comment><USER20> > he could've thought that the simple implementation is faster but missed the > fact that skip is implemented in assembly

It's not; the compiler is just fairly decent at transforming string manipulation routines.

<comment><USER43> >As Tim explained to me, first off, the reason why VB does this seemingly bizarre "find the first character match, then check if query is a prefix of source" logic is because the skipto method is not written in the naive fashion that I showed here. The skipto method is a single x86 machine instruction.

oh my bad then, from this text it sounded like it was written in assembly.

</comment></comment></comment><comment><USER44> I'd say that for widely used library code it makes sense to implement an efficient algorithm. By its very nature the context in which a library routine will be called is unknown and so it must be prepared for everything. Also for widely used code the amount of total saved machine time can be quite substantial.

In the story the senior dev makes a judgment call (that this routine will be used in LOB applications where the worst case is unlikely to appear so the implementation is OK) which is probably correct, especially considering other priorities. And of course senior devs are much better equipped to make this kind of calls than juniors, but they still can and will guess wrong.

> Moreover, Tim explained to me, any solution that involves allocating a > table, preprocessing strings, and so on, is going to take longer to do all > that stuff than the blazingly-fast-99.9999%-of-the-time brute force > algorithm takes to just give you the answer.

That's why a good implementation will dispatch to the best algorithm at runtime!

</comment><comment><USER45> Of course, if this code were running in a server, or if it were part of a library that was widely used, then suddenly you have the potential for a DoS vulnerability.

The narrative would then be that the microseconds you saved all those devs over the years were wiped out when hackers took down your system.

</comment><comment><USER46> The senior dev knows the system, knows what they can get away with, and has choices to use those knowledge powers. A newbie will always follow the programming rules, like never going over the limit on a hwy. as they can't take much calculated risks

<comment><USER46> Senior has a lot more types of ammo to use to solve problems let's just say

</comment></comment><comment><USER47> > NO! YOU CAN'T JUST USE BRUTE FORCE HERE! WE NEED TO USE SEGMENT TREES TO GET > UPDATE TIME COMPLEXITY DOWN TO O(LOG N)! BREAK THE DATA INTO CHUNKS AT > LEAST! OH THE INEFFICIENCY!!!

I'm the opposite of this stereotype, and I think there are more like me. Two reasons as to why:

(1) Psychological:

I never had this. As a junior dev, I don't like to optimize because I feel a bit of pain when I need to moderately focus. I can do it, and I've done it quite a lot. In that sense, I've experienced quite a bit of pain in my life. It's something I've learned to live with. And when I have to focus, I prefer to focus all the way, because whether I focus on 50% or 100%, the pain is roughly similar. This leaves me in a state of either being lazy(ish) and wanting to program in a simple and understandable way versus being willing to go as deep into a topic as I would need to and focus on all the details step by step.

When I'm intense, I also am still sympathetic towards simple code because I know that I understand that in both states. I only understand complicated code when I'm focused.

(2) There are enough CS grads that know better:

Also, on another note. Efficiency analysis is simply not taught at university. Parts of it are taught, but they're never connected to real world cases.

For efficiency analysis (note I haven't done any but I've read a thing or two and talk with a friend who is a performance engineer quite regurlarly about it) I think there need to be a few perspectives in check:

1\. What is the user's actual behavior.

2\. What is the behavior for malicious attackers (if applicable, Intel should do this more, to my knowledge they are doing it more now).

3\. How does the compiler translate it to assembly?

4\. How does it theoretically look? Specifically: worst-case, best-case, average-case in both theoretical and empirical sense.

Concluding:

I only have one year of experience in software development, where no one cared about performance yet I know better than to look only at the theoretical speed. So I guess I'm a counter example to the stereotype. I'm not alone. Any CS student who reads HN has a high chance of stumbling upon articles like this and will know that performance analysis is not only about calculating the space-time complexity.

<comment><USER25> The "malice" aspect is a great one and I did not go into that in this post because of course back in the 1990s we were not at all concerned that someone would _maliciously_ craft inputs that would slow down this algorithm.

In modern code we'd want to do a threat model that considered the consequences of untrusted inputs.

<comment><USER47> Neither did Intel :P

Come to think of it, neither do beginning game-designers. They think that players will play their game as intended.

I like that you're standing still at the malice part as it is becoming seemingly more important every day.

</comment></comment></comment><comment><USER48> This is the meme referenced by the blog post:

[https://i.redd.it/lmrf72ko0ro41.png](https://i.redd.it/lmrf72ko0ro41.png)

</comment><comment><USER49> Admittedly clueless question: what does 'brrr' mean? (I'm not a software dev and idioms that may be obvious to others are unfamiliar to me.)

<comment><USER50> It originated from a meme of the Federal Reserve printing more monopoly money. "Printing machine goes brrrr". As they turn the crank ever faster making the printing machines smoke.

<comment><USER51> More info: [https://knowyourmeme.com/memes/money-printer-go- brrr](https://knowyourmeme.com/memes/money-printer-go-brrr)

</comment></comment></comment><comment><USER52> Can someone explain the bugs in the code samples? The author says they're there but I honestly can't find them.

<comment><USER25> Hint: what is the correct behaviour of this method when given empty strings? Every string contains the empty string as a substring.

<comment><USER52> Oh, I'd assumed disagreement on behavior of query="" between the two code samples meant it was UB and was looking for crashes/invalid memory accesses.

<comment><USER25> A Visual Basic program is not allowed to have undefined behaviours like a C program; InStr has a specification and that specification has to be implemented; that spec includes defining the behaviour for all inputs.

There's also no null handling here, which was a deliberate omission for clarity. In practice, the convention used inside the VB source code is that null string pointers are semantically the same as empty strings, which introduces some complexities.

<comment><USER52> ah neat, thanks!

</comment></comment></comment></comment></comment><comment><USER53> One of my job tasks was improving our custom string library. In VB! Sure InStr was slow: but we were trying to do "starts with" across very long strings. Sure, it worked, but a slightly smarter solution was 100 times faster. Upon finding it I went on a search, I found it written nearly identical 10 years before me, in a different version of a string library (hint, that one was faster).

The trick to knowing we needed to improve it: profiling!

<comment><USER54> You're telling me that a bigger instance size in AWS isn't always the solution?

</comment></comment><comment><USER55> This isn't always the case that simplistic algorithms don't cause issues Bruce Dawson keeps on finding O(n^2) algorithms in windows that keep on biting him. I'm always impressed with his work.

[https://randomascii.wordpress.com/2019/12/08/on2-again- now-i...](https://randomascii.wordpress.com/2019/12/08/on2-again-now-in-wmi/)

</comment><comment><USER56> I dislike the mentality that one must "struggle" to be patient with new devs and that it's "more than they deserve."

Is it really so hard to help other people learn, and to accept that the only advantage you have on them is starting earlier?

<comment><USER25> I take your point, but let's be fair. My attitude was "this code is bad and I'm going to demonstrate my skill by improving it" when it should have been "please teach me what design and implementation concerns went into the choice of algorithm here". I was lucky to get a gentle and thoughtful correction for my presumptions.

<comment><USER57> Kudos to you first for recognizing your own error and second for openly admitting it.

I think there many things to consider here. For new developers, I'd encourage you to look for those "old guys" who really know their stuff. There's a lot of unmined gold you can discover there if you find the right ones. I think us older developers would do well to imitate the patience and kindness of Tim Paterson more often. I guess what I'm saying is both sides could do with a huge dose of humility. I know at times I've been the youthful dev out to one- up the "old guys", and I've been the senior dev thinking "these kids today" to myself when dealing with those with a lot less experience. And both of those are bad.

Also, there are many times when a young guy fresh out of college spots a problem, finds a great solution, and makes things ten times better by just doing it! If you're in the business for a long time, it can become too easy to be cynical, and lose your enthusiasm.

I think the best thing we can do is try to let the good stuff from both sides rub off on each other.

</comment></comment></comment><comment><USER58> I've noticed there's a similar form of this at the sr. dev/grizzled veteran divide.

The sr. dev will look at "old" code in horror and be sure the only way to make it perform is to port it to a newer language/framework/architecture.

The grizzled veteran will profile the code, think, and tweak a few lines. No fancy new things or big re-writes needed.

</comment><comment><USER59> Sometimes it's not just coding tools/techniques where new grads can benefit from a bit of oldster wisdom, like that one time I convinced a new grad it was wiser to slog through the bureaucratic approval process for a new api than attempt to hack into our company's Oracle Financials db.

</comment><comment><USER60> This reminds me of how insertion sort is the most efficient sorting algorithm for small values of n. I remember new-grad me always dismissing insertion sort in every situation because of asymptotic complexity. Engineers are supposed to find the most pragmatic solution without biases.

</comment><comment><USER61> To be fair, there have also been plenty of times in this situation where the senior dev was wrong. You were right to question things and we should make sure to continue to encourage questions. The difference between a new grad and a senior dev is that the senior dev has the real-life experience to make the "yes/no" decision as to whether the new grad's input actually makes things better (e.g. it could be true that it doesn't matter if it is asymptotically faster if we are always working with small data). It's also a trait of a senior dev to be able to stay level-headed in these situations

</comment><comment><USER62> Edit: I thought I was responding to someone, but I can't find the comment now.

I find that being open to new ideas, and allowing some time to prove them out rather than deciding beforehand, is the best way to find ideas that move the needle.

Senior comes to you with an idea? Great, prototype it, prove it out. Junior comes to you with an idea? Great, prototype it, prove it out.

Of course, you need to allow some time for prototyping.

When I ran teams, I told them part of their job was to spend the last half of Friday (unless emergency) prototyping their ideas and presenting their favorites at some point.

No one works the last half of Friday anyway, unless it's on this.

</comment><comment><USER63> Well, this is a nice example of lack of knowledge flow. The senior developer spent his time explaining things that should have been put in the procedure's comment. Yes, that's what comments are for.

</comment><comment><USER64> The real lesson here should be: don't make assumptions about performance. Take real world use cases and measure!

That's what my professors drilled into me (I specialized in high performance computing) and it's served me well.

</comment><comment><USER65> On a larger architectural scale, see: Use Boring Technology

[http://boringtechnology.club/](http://boringtechnology.club/)

Also described as: "how to be old, for young people"

</comment><comment><USER66> As a new grad myself, I completely agree with the author's freak out when seeing "inefficient" looking code. But I feel like this applies to basically all aspects of a company life as a new grad software engineer. For me at least, there seems to be a lot of inefficient things going on in every aspect of the company. Maybe the author is right in that there is a reason behind those seemingly "inefficient" things. However, the inefficiencies are there because sometimes, people who have been working there for years just have become used to it.

<comment><USER58> One thing you learn over time is many of those code horrors are there for a good reason, put there by someone solving a real problem, in the best possible way given time constraints. It is just the reason is lost to history. This is one reason the "big re-write" almost always fails. You are throwing away all those hard learned lessons just because they aren't apparent on reading of the code.

That is also true (perhaps less often) for byzantine process related procedures.

</comment></comment><comment><USER67> Seems like the original developer should have left a comment about why their nested for loop was the right implementation (if they knew it was). Would have saved everyone a lot of time.

</comment><comment><USER68> With the world of developers becoming "senior" at faster and faster rates, we're asymptomatically approaching the demise of these questions, no?

<comment><USER58> Certainly at any startup "sr" is simply a self assigned title.

</comment></comment><comment><USER69> I would use the standard ISO C strstr instead of writing the function they are calling find.

Yes, we had strstr in 1994; it was in the 1989 ANSI C standard.

On a very small system, strstr will probably just be naively coded, to save space. On a big system, it might use Knuth-Morrison-Pratt or Boyer-Moore. I don't have to care; by using strstr, that decision is taken care of.

<comment><USER25> As I noted in the text, the actual problem that we had to solve was complicated by a great many factors not the least of which was the fact that the library had to handle strings from different string encodings.

</comment></comment><comment><USER70> I think it is good when new grads have the knowledge to see that those things don't look right and can articulate how and why it should look different.

After all, when you come across a problem, that does not contain just 100 chars, it is very helpful to know what you can use to create something that still works with reasonable resources.

</comment><comment><USER71> The only nested loop implementation I've ever changed for performance was due to the fact that there was a freakin' database call in the inner loop. All I did was refactor the data structure so that the db call was done outside the outer loop. Instant 20x improvement in performance.

</comment><comment><USER72> Were the x86 string instructions much faster in 94? That was 486/Pentium era, right? IIRC this has varied over the years with sometimes slow microcoded string instructions and then faster improved instructions again.

</comment><comment><USER73> But Boyer-Moore is so pretty!

      abcdefghijklmnopqrstuvwxyz

If the 26th char isn't _z_ , jump along 26 chars! (More complex, and more cache misses, if _z_ is repeated in the search string).

</comment><comment><USER74> The explanation behind the code is exactly the kind of thing that belongs in a comment. The why, not the what. So even if it wasn't a failure of programming, it was a failure of documentation.

</comment><comment><USER20> > The skipto method is a single x86 machine instruction.

That's not always a good thing, especially on modern hardware. And obviously, the "single instruction" doesn't mean it'll take bounded time to execute…

<comment><USER75> Tangentially to your point, here's something I haven't thought about much: when these instructions get an interrupt, I imagine they've updated (r|e)si and (r|e)di, (r|e)cx etc. to reflect where they are in their copy or scan loop. So if you get a page fault in the middle, then the kernel does enormous amounts of work in response to it, then resumes that single instruction, it resumes in the middle of the loop, not the start.

So to reiterate one aspect of your point, there might be lots of work, written in C, that occurs in response to the page fault in the middle of your "hardware-backed" single instruction. On top of all the other complexities of cache vs memory access etc. that make scanning and copying memory complicated no matter which way you do it.

But probably in the heyday of Visual Basic, and especially the DOS-based BASICs that preceded it which wouldn't have had virtual memory at all, all of this is less of a concern. The story takes place in a simpler time which serves as a plot device to better illustrate the point.

<comment><USER76> Pretty pointless as said page fault would occur no matter how you access the string. Besides, the page in question would very likely be already present.

<comment><USER75> > Pretty pointless as said page fault would occur no matter how you access the > string.

When did I dispute this?

> Besides, the page in question would very likely be already present.

Really? How are you so sure? I guess you can just abandon all notion of virtual memory and mmap then. 'Cause it ain't gonna happen.

<comment><USER76> >> Besides, the page in question would very likely be already present.

> Really? How are you so sure?

It was in a BASIC interpreter. Most of the time string needle in a haystack search is done, haystack is relatively fresh, almost certainly on a page that is present. Might not be in CPU dcache, but that's another matter.

</comment></comment></comment></comment></comment><comment> 08-15 The way I read this, TIM FREAKIN' PATERSON, the man who wrote the most hated "operating system" in history, put an algorithm with a nasty performance bug into the standard library of VB, and conveniently forgot to document that this function is no good for large and/or repetitive inputs. Confronted with his blunder, he not only doesn't correct his blunder, but instead condescendingly proclaims that those inferior VB coders would never need long strings, just like 640kb ought to be enough for everybody, and if they did anyway, they'd surely use a library written for the purpose by a real programmer.

The arrogant prick should have listened to the new grad.

<comment><USER25> And that you would read it that way says more about you than it does about Tim, believe me.

</comment></comment><comment><USER77> There's some good wisdom in this story. It reminds me of that article posted here about a more page cache efficient b-trees vs. Knuth's theoretically ideal version

</comment><comment><USER78> There is another type/layer of new grad - the kind without CS background and not being able to make a right solution (let alone balancing different concerns)

</comment><comment><USER79> The true mark of a Senior dev would be commenting the code in question with the thought processes and decisions that lead to the chosen approach.

</comment><comment><USER80> They could use naive solution for like len(query)<12, and then implement the asymptotically good solution for other situations.

</comment><comment><USER58> A CS degree helps you understand why something is slow, and how to make it faster. Experience tells you when it matters.

<comment><USER81> That's not even the case in this story though - the implementation _was_ faster, _for the usual way it was used_.

</comment></comment><comment><USER82> New Grad: I'd use a linked list here because insertion into the middle is O(1) rather than O(n).

Senior Dev: Linked lists have very many more cache misses than do vectors, and the difference between hitting cache and hitting main memory is such a huge constant factor that for most reasonable list sizes it never makes sense to use a linked list. Use a vector. Checkmate, smug Lisp weenies.

<comment><USER83> Yeah, the Lisp world figured out cdr-coding in the 1970s and had moved on to chains of vectors by 1985 according to [https://cpsc.yale.edu/sites/default/files/files/tr362.pdf](https://cpsc.yale.edu/sites/default/files/files/tr362.pdf). Fortunately they avoided changing the API to make this tradeoff.

<comment><USER82> Afaik the only modern Lisp implementation that actually uses these techniques is Clojure.

</comment></comment></comment><comment><USER84> Aside - I wish the examples were written in pseudocode without c pointer and type clutter.

<comment><USER25> Noted.

</comment></comment><comment><USER85> Most FAANG job interviews would fail you if you did the brute force solution, it seems.

<comment><USER20> I feel that most will be sympathetic if to you explain why you did something a certain way and showed that you understood the different approaches available.

</comment></comment><comment><USER86> Everyone who has done profiling knows that (almost always) the performance problem is in the part that you least expect it. But also that sometimes you wrestle to improve the performance of an algorithm hitting a hard wall and than someone comes up with an idea, often resulting from a fresh look on the problem, that results in an improvement of several orders. I guess that performance is at least as counter intuitive as statistics. The same is true for some other things like scalability and reliability.

Actually, I think that it scares the hell out of most of the developers that it is so difficult to get a grip on these things. It is so easy to think that there is a simple solution, a grand idea that will fix the problem. I still find myself falling in the trap and this after having developed software for over 30 year. It is the Dunning–Kruger effect over and over again. I guess it more that as a more senior engineer, you have experienced a little more often.

<comment><USER87> > I guess that performance is at least as counter intuitive as statistics.

I don't think this is really true. After you've optimized enough code over the years, you start to get a sense for bottlenecks, and your code is usually "fast enough" even on the first try. When it isn't, finding the problem with a profiler is usually pretty straightforward.

</comment></comment><comment><USER88> I understand this as phenomenon as the new grad and the senior developer are optimizing for different things. The new grad is focused solely on the asymptotic complexity of the code. It doesn't matter how slow or how complicated it is in practice, they are solely focused on using the fastest data structure asymptotically.

The senior developer optimizes a different set of criteria:

      1) How hard is it to understand the code and make sure it's correct.
      2) How fast the algorithm in practice.

There are several different reasons why the performance of the algorithm in practice is different than the performance in theory. The most obvious reason is big-O notation does not capture lots of details that matter in practice. An L1 cache read and a disk IOP are both treated the same in theory.

A second reason is the implementation of a complex algorithm is more likely to be incorrect. In some cases this leads to bugs which you can find with good testing. In other cases, it leads to a performance degradation that you'll only find if you run a profiler.

I one time saw a case where a function for finding the right shard for a given id was too slow. The code needed to find from a list of id ranges, which one a given id fell into. The implementation would sort the id ranges once ahead of time and then run a binary search of the ranges to find the right shard for the id. One engineer took a look at this, realized that we were doing the shard lookups sequentially, and decided to perform the shard lookups in parallel. This made the code faster, but we still would have needed to double the size of our servers in order to provide enough additional CPU to make the code fast enough.

Another engineer hooked the code up into a profiler and made a surprising discovery. It turns out the implementation of the function was subtlety incorrect and it was sorting the id ranges _on every call_. This happened because the code sorted the id ranges inside of a Scala mapValues function. It turns out that mapValues does not actually map a function over the values of a hash table. It instead returns an object that when you look up a key, it will look up the value in the original hash table, then apply the function[0]. This results in the function being called on every read.

The solution was to replace mapValues with map. This dramatically improved the performance of the system and basically brought the CPU usage of the system down to zero. Notably, it would have been impossible to discover this issue without either knowing the difference between map and mapValues, or by using a profiler.

[0] [https://blog.bruchez.name/2013/02/mapmap-vs- mapmapvalues.htm...](https://blog.bruchez.name/2013/02/mapmap-vs- mapmapvalues.html)

</comment><comment><USER89> This Dilbert went around the office a lot when I was a new employee. The numbing is real...

[https://dilbert.com/strip/2003-02-16](https://dilbert.com/strip/2003-02-16)

</comment><comment><USER90>
        Nested for-loops go brrrrrr

lmao! But #truth.

</comment><comment><USER91> tldr; needle in a haystack, rolling polyhash

</comment><comment><USER92> I have no CS degree or STEM degree.

Recently I worked on the same type of project as someone with 10 yrs of experience & a CS degree from Stanford.

A few months later, I created a project, and had a manager with a CS degree. However, when I left, that manager was unable to pickup where I left off, and he ended up leaving soon after.

I have less years of experience, but to me, what matters more is the time within that experience which was put into a relevant business model, product built, or past projects. I.e. a Senior Dev with a CS degree, vs. a New Grad with a Business Background & SWE Experience. It's apples to oranges in many cases.

Also, I'd echo another comment here:

>"daxfohl 1 hour ago [-]

> As a senior dev, I wish that I could say I always knew more than my interns, > and that all the code that's there is because it was carefully planned to be > that way.

>But more often than not, I don't, and it's not. "

<comment><USER93> There are indeed many not-really-programmers with CS degrees.

On the other hand, sometimes I'm handed a program written by a new grad to maintain/fix/improve, and rapidly determine that it's less work to just chuck it in the bin and start over.

One of the major differentiators between a newbie and an old hand is knowing how to create a piece of software that those who work alongside you or come after you can understand, maintain, and improve.

</comment></comment><comment><USER94> Sure. But most senior devs are not Tim Patterson.

<comment><USER95> but it's not uncommon for jr. devs to believe every piece of code deserves the most efficient runtime. Runtime speed causing projects to fail is very uncommon. What does add an incredible amount of work time is combing through a codebase looking for micro optimizations. I've never once seen a jr. dev who claimed to care about efficiency start by writing benchmarks over large parts of the system and using that to find real bottlenecks. No, they always comb through the code trying to impress the sr. dev. with their algorithmic knowledge.

<comment><USER23> > _Runtime speed causing projects to fail is very uncommon._

That's true. What is common, however, is bad runtime performance losing you users and bleeding your money. Not doing dumb things (like using a list where a vector would do), and taking a moment every now and then to go over your product with a profiler and fix the biggest bottlenecks early, can save you a ton of money in cloud bills (it might even turn out that your product actually doesn't need to horizontally scale _at all_ , giving you further reduction-of- complexity benefits). Or you might end up delivering features that were impossible to do with bad performance (see e.g. [https://news.ycombinator.com/item?id=22712103](https://news.ycombinator.com/item?id=22712103)).</comment></comment></comment>


Rails 4.0 Whirlwind Tour Presentation - <AUTHOR> http://highgroove.com/articles/2012/10/16/rails-4.0-whirlwind-tour.html

<comment><USER2> So as someone out of the rails world for a few years, I found the line about the webserver needing to be "thin/rainbows/puma _over_ unicorn" hilarious, since I have no idea what any of those words mean.

Rails-world with your changing of servers and plugins-of-the-week, never change.

<comment><USER3> Thin/Unicorn/Rainbows have been around for like 3+ years.

</comment></comment><comment><AUTHOR> For anyone that lives near Atlanta, this was recorded at <http://www.meetup.com/atlantaruby/>. Our next meetup will be November 14th if you want to hear more awesome talks like this one. </shameless plug>

<comment><USER4> I've been to that meetup before, very high quality, many talented people, and interesting talks (and lot's of recruiters). They also have a Saturday RoR beginners group if anyone is interested.

</comment></comment><comment><USER5> Argh. I'm on an iPhone and I can't read this because they made their JavaScript just blindly redirect to their mobile site without any regard to the specific page I was on. I wish people would stop doing that, or at least provide a way to opt out of the redirect.

<comment><AUTHOR> Might be a little late, but the "Visit Full Site" link should take you to the correct page.

<comment><USER5> Thanks! It worked great!

</comment></comment></comment><comment><USER6> Of course the most used ActiveRecord method is going to be the one that changes most frequently! Let's change it every release!

<comment><USER7> You referring to the removal of deprecated methods from the 2.x branch?

<comment><USER8> I think the parent is referring to the changes to ActiveRecord::Base#find and its convenience helpers, #first, #last, and #all. I'm not sure what else it could be. It's definitely true that the semantics of the finders have changed and they're huge gotchas to newbies to Rails. Here's a brief review:

In rails 2.x:

        Post.find(:first) # => First record, determined by db engine
        Post.find(:all)   # => All records
        Post.find(1)      # => Find record with id 1
        Post.first        # => Same as find(:first)
        Post.all          # => Same as find(:all)

Rails 3.x

        Post.find(:first) # Deprecated, use #first/#all
        Post.find(1)      # Same as 2.x
        Post.first        # First record, determined by db engine
        Post.all          # All records or force execution of a Relation

Rails 4:

        Post.find(:first) # RecordNotFound, could not find record with id :first
        Post.find(1)      # Same as 2.x
        Post.first        # Ordering is enforced, use #take to simulate old #first
        Post.all          # Always returns ActiveRecord::Relation
        Post.all.to_a     # Force query to execute, avoid this!

I'm not particularly unhappy about any of the changes as they definitely make it more consistent. With the move to ARel in the 3.x releases, they definitely discouraged the use of #all to force query execution (build up a query, iterate over it, don't worry about executing it).

I'm actually quite glad they fixed the db ordering gotcha present when using #first and #last. It drove me nuts when I first ran into it and it has affected almost every Rails developer I've talked to.

<comment><USER6> Yes, but I've been using Rails long enough to remember when they removed `Post.find_first`, and there was even a time when `Post.find(:first)` was the only version - `Post.first` was added late in the 2.x series.

<comment><USER8> Wow I didn't actually know that. I started using Rails seriously around 2.3 so I always wondered why everyone was always using find(:first) instead of just first. I never even knew about #find_first!

</comment></comment></comment></comment></comment><comment><USER9> Rails newbie here: Can someone explain how ActionController::Live compares to websockets and other similar technologies? Pros + Cons + if my comparison is even sensible?

<comment><USER10> WebSockets enables two-way communication between the server and client.

ActionController::Live is merely an improvement of the HTTP Streaming functionality where the server will send HTML (or other data) down to the client part way through the request. So the server can send data, but not receive it from the client.

If you want to stream data to a client, then you can keep the connection open and just never "finish" the page. If you do this you'll have to be careful with concurrency etc, hence the requirement to use Thin/Rainbows/Puma not Unicorn.

A better comparison would probably be the new HTML5 Server-Sent Events (SSE) functionality. Though I'm not too familiar with that spec yet, so I can't comment on that.

</comment></comment><comment><USER11> I'm really liking live streaming, opens up rails to be a simple back end for simple games.

</comment><comment><USER12> Anyone know if Jruby is compatible already, or will I have to wait for it to catch up.

</comment><comment><USER13> Aaron Patterson (tenderlove) had a blog post where he talked about the necessity of refactoring rack. I guess that is a larger project that isn't happening right now but that should lead to real performance improvements.

</comment><comment><USER14> Under the "Most Important Change" header: [http://speakerdeck.com/u/alindeman/p/rails-4-dot-0-whirlwind...](http://speakerdeck.com/u/alindeman/p/rails-4-dot-0-whirlwind- tour?slide=4)

I was wondering why so few police departments were using Rails.

* on a more substantial note, the biggest migration changes seem to be requiring Ruby 1.9.3+, elimination of 2.x "find" syntax, and no more vendor/plugins.

<comment><USER15> And of those migration changes, the move to 1.9.3 will be the biggest change for shops still on 1.8. If you're already on 1.9, the move is straightforward.

Switching find syntax over is rather simple, though tedious.

Gemifying a plugin takes 30 minutes or less in my experience. It will take more time if you haven't done it before, and more time beyond that if you've never made a gem before.</comment></comment>


Ask HN: Where do you draw the line between technical and non-technical? - <AUTHOR>

Forgive my naivete, but since I started reading HN earlier this year, I've seen the terms "technical" and "non-technical" thrown around a lot, mainly when it comes to founders, but not limited to that.<p>From my perspective, it seemed implied that "technical" is synonymous with "coder/developer" and "non-technical" being "everybody else".  So, I ask, where do you draw the line? <comment><USER2> That's pretty much it. Either you code or you don't.

<comment><AUTHOR> To me, what you said seems like the other technical people that don't write code would be considered "non-technical", which doesn't make sense to me. I, for example, don't write code but I'm far from non-technical. So... I'm still confused.</comment></comment>


Trial claimed to show a 4 and 5-day work week are equally productive. It didn't - <AUTHOR> https://medium.com/@robertwiblin/a-widely-publicised-trial-claimed-to-show-a-4-and-5-day-work-week-are-equally-productive-655dac3aee94 <comment><USER2> The article here boils down to arguing that the answers to these three questions aren't representative of productivity:

1\. Meets formal performance requirements of the job

2\. Fulfills responsibilities specified in job description

3\. Performs tasks that are expected of him or her

As an employee, those should cover everything I'm evaluated on; any company that claims this isn't enough is either horribly mismanaged or trying to exploit its workers by requiring them to do things they didn't sign up for.

<comment><USER3> That's a view that works if you want a static job, like a passport inspector. No one expects or wants them to go "above and beyond." But in a company like Google, the work that needs to be done is far harder to define, and change frequently. You cannot expect to be promoted or even stay employed if you are just planning on doing what was specifically enumerated in the job description when you applied. for the job.

<comment><USER2> I imagine the google job description for a software engineer is something like:

* Write and maintain software in accordance with business strategy

* Assist other technical staff when their duties overlap your area of responsibility

* May be required to be available 24/7 up to 15 days per quarter

* Periodically provide feedback to management about coworkers' performance

* Interview and evaluate candidates for technical positions

</comment></comment></comment><comment><USER4> The less number of days people are expected to work, the more advantage motivated and ambitious employees have. If everyone has to work everyday, the only thing a person can do is to work longer hours, which have a decreasing marginal gains every extra hour worked. But with a weekend, an employee now can use 2 extra days to get ahead, theoretically doing 40% more work.

With a 3 day weekend, this goes up to an eye popping 75% more work, or even just a 25% increase for one extra day.

Because of this, I contend that a 4-day work week is highly unstable and that employees are going to naturally fall into a 5 or 6 day pattern to get ahead.

For a long time, people have been talking about leveling off work hours since productivity has/will go up. But the reality is that no one doesn't want to work. No one wants to just work 4 hours a day and be done with it. We want to word harder and do more and make more money and be more successful. That's who we (humans) are and it's foolish to think we can change that.

<comment><USER5> It is foolish to think people actually want to work more and that we tie our success to working harder and making more money.

<comment><USER4> Do you have a better metric in which we all can compare ourselves by? Because I know that the first thing everyone asks each other when they first meet is "what do you do?" If work doesn't matter, why does everyone ask each other that question?

<comment><USER5> Why do we need to compare ourselves based on work? When I ask people what they do it's a general question. I am data scientist yet my friends are auto mechanics, in sales, teachers, work in the veterans department at colleges etc... We don't compare ourselves based on our occupation.

</comment></comment></comment></comment><comment><USER6> Would be good if the title could be edited so the word 'This' isn't missing at the start:

"This trial claimed to show a 4 and 5-day work week are equally productive. It didn't."</comment>


A woman's take on GitHub: it's structural sexism. - <AUTHOR> http://wizgeneric.blogspot.com/2014/03/overt-sexism-or-structural-sexism.html

<comment><USER2> _" First point of structural sexism: wife of founder has a role in the company, but it is undefined and she is not formally employed by the company. This is sexism, pure and simple. Because of her relationship and gender, she is excluded from a formal role in her husband's company, but is still expected to 'support him.'"_

This is pure speculation. Maybe the wife doesn't want a real job in the company (she may have a job somewhere else, or be wealthy enough not to need a job). Maybe the husband doesn't want his wife hanging around the company but is uncomfortable telling her to mind her own business.

<comment><USER3> The author is either very clever or very dumb, and I honestly can't tell which.

She points out that sending a women to deal with another women is sexist. The (presumed) reasoning is that women are people, and shouldn't have be given special treatment (positive or negative).

Yet the title of her post SCREAMS "listen to me, because I am a women and for that reason my perspective deserves special treatment".

If her perspective has value because she is a women, wouldn't the wife the the founder have the EXACT same additional value of being a women.

Again, either super-clever, self-referential and meta, or dense.

</comment></comment><comment><USER4> > My husband, who is also a developer, said I should blog about it because he > didn't see any sexism at all in the story until I pointed it out to him.

I could not see any sexism in this occasion until reading this post either. The reason is that to me, (and probably to the OP's husband and many others) sexism is "Shut the f.ck up, this is men's business". Thanks a lot for this enlightening post.

</comment><comment><USER5> Looks like there are other addressable issues with the situation that could avoid saying "because she's a woman" completely. The author almost said it at the end of the post.</comment>


Facebook Instant Articles create a better reading experience for users - <AUTHOR> https://www.techinasia.com/talk/facebook-eating-internet-with-good-ux <comment><USER2> Good UX? I just uninstalled Facebook Messenger AGAIN on Android because it was taking 17% battery for doing absolutely nothing. Thanks for reminding me how much I hate everything about them. I use Facebook a lot less since I uninstalled their shitty apps and I don't care for their browser clients either.

Let me know when I can get a simple list of what happened on Facebook on my feed by DATE and I'll care again.

<comment><USER3> I rarely check my Facebook on my phone but when I do, I use their website.

But for a few days now, every time I tap on the messages icon it bounces me to the Google store app for their messenger. I literally cannot see my messages anymore!

A workaround is to change the user agent (is that the word?) by requesting the desktop site. Then, the m.facebook.com domain is a bit more tedious to use but it works and I can see my messages. The www.facebook.com domain is unusable on your phone (rescaling is completely broken and text boxes don't work on my phone, so I guess they didn't really do a good job there).

So now I'm stuck using the mobile version of their website as seen from a desktop browser.

Great User Experience!

<comment><USER4> > I guess they didn't really do a good job there

Not if their goal was to make the non-mobile version of their site usable on your phone. But if their goal was to make the non-mobile version of their site _unusable_ on your phone, they did just fine. (Why would they want to do that? To encourage people to use the mobile version. Why would they want to do _that_? Among other reasons, to make them use the Messenger app.)

Yeah, that's pretty conspiracy-theory-y: it implies that Facebook did something that was unequivocally bad for user experience, in order to push people into interacting with their services using the methods they prefer. But then, disabling messages in the mobile website to push people into using the Messenger app fits that description perfectly too.

<comment><USER3> > that's pretty conspiracy-theory-y

I don't think that it counts as a conspiracy theory at this point. I think their intent is very clear.

Here's Facebooks strategic cookbook according to my experience and opinion:

       1. Advance into new territory
       2. Make it nice and cozy to attract enough people
       3. Fence it off and lock people in
       4. Go to step 1

Examples would be:

\- Anonymity

\- XMPP support for their chat

\- making the time line a clusterfuck (is it actually still a _time_ line or what do the call it now?)

\- the reach of public posts on business sites (unless you pay)

\- the whole thing how facebook videos are treated unequal to videos from other sources (probably everything originating from facebook sources is treated as more relevant in your timeline, who knows...)

\- we also have the facebook articles thing where publishers will likely leave a few kidneys behind when they try to get out of it again

The fun thing is that as soon as people feel comfortable using a certain feature, they don't really notice how they get locked in. Like a prison with walls so far you can't see them. Keep living inside and build your life and house and whatever have you. When the walls close in, you either leave everything behind or rearrange yourself according to your new overlords.

Edit: formatting

</comment></comment></comment></comment><comment><USER5> Facebook and good UX? Ha! Good one.

I'm a UX designer and Facebook baffles me. Maybe I'm a bit too old or I don't use it enough, but I find it so unintuitive - there's all kinds of options, corners and dead ends where things may or may not be hidden. And then once I've found something, getting back there again is almost impossible.

It just doesn't lend itself to a consistent mental model.

<comment><USER6> what site is a great example of good UX?

<comment><USER5> One of my go-to examples is [http://www.gov.uk](http://www.gov.uk). Obviously a very different site to Facebook, but the way it combines the content from hundreds of individual sites while still making it easy to navigate is impressive.

To be fair, Facebook's UX is always going to be a bit of a nightmare just due to the sheer volume of disparate features stuffed in - the 'iTunes effect' as I've just called it - so the move to focused apps for specific features is probably a good thing.

To be not so fair, I get the suspicion that the UX is left deliberately confusing in places, especially the constant rearranging of privacy settings, to get people to share more than they would otherwise.

<comment><USER7> I know it's text based but still, the gov.uk is blazing fast. Looked under the hood, seems like they're using client-side template rendering via Mustache, and JQuery.

Not sure what the back end is written in, saw a reference to Flask in a javascript comment, so maybe Python.

</comment></comment></comment></comment><comment><USER8> The title overpromises and under-delivers. FB's mobile app prefetches articles that are published with the 'Instant Articles' feature, a publishing platform similar to Google's AMP. This avoids the page-load pause that would occur by visiting an external link on a third-party host in an external browser.

Of course, this prefetching isn't free -- the user is paying in increased data and battery usage. The content publishers, and the users who do read the content are happy. The most informative portion of the article is a picture showing better conversion rates using 'Instant Articles', but image is directly lifted from Facebook's marketing of the feature.

It's ironic that the article states Instant Articles "may lead to a reduction of spammy 'content marketing' that dominates the Internet, where we see unoriginal listicles churned out with an underlying purpose of making conversions and sales", even though this article is essentially content marketing for the purpose of promoting conversions and sales. But the takeaway for me was I didn't know Facebook has a competitor to AMP.

<comment><USER8> Submission title has now been changed from the article's original: "How Facebook is eating the internet with good UX" to "Facebook Instant Articles create a better reading experience for users".

</comment></comment><comment><USER9> This article has more to do with publishing platforms than UX but I wonder when we will see the first real businesses founded on the idea of producing high quality news content while completely abandoning publishing platforms and posting direct to Facebook/LinkedIn/other.

It seems like all credible news agencies try to compete not just on having the best stories and coverage but they also on building a distribution platform. Presumably they do this because they think it's the best path to monetization but I don't see the exact angle there. The NYTimes seems to have done this well but most other self-built publishing platforms aren't that great. For example I find the WSJ to be pretty obnoxious and it's considered a major paper.

I wonder why we haven't seen more agencies/companies that only handle content creation but don't self distribute. (On the flip side of that, more tech companies that only build a distribution platform but produce no content.)

</comment><comment><USER10> Notifications:

* Random page 1 blah blah blah live video *

* Random page 2 blah blah blah live video *

* Random page 3 blah blah blah live video *

* Random page N blah blah blah live video *

> No option to disable globally those notifications

Yeah, sure, good UX...

<comment><USER11> > No option to disable globally those notifications

That's not true, go to Settings -> Notifications -> On Facebook -> and select _All Off_ for _Live Videos_

<comment><USER10> That option didn't exist a few months ago[1], so expecting users to proactively hunt when they implement an opt-out to an annoying feature is also bad UX:

[1] [https://www.facebook.com/help/community/question/?id=1020742...](https://www.facebook.com/help/community/question/?id=10207426382755975)

</comment></comment></comment><comment><USER12> I wouldn't say Facebook as good UX so much as so many other websites have downright trash UX. Being the best turd in a toilet isn't much to brag about.

</comment><comment><USER13> The Facebook UX has something in common with their CEO's dress sense. It looks like shit.

</comment><comment><USER14> Since people are venting, I'll contribute with one more frustration I don't often see. The one thing I'd think facebook would be good at, it is not, and that is: Finding events.

One of the main reasons I ever started a facebook account was to be able to follow events happening in the city I live in. Now I am in a new city and don't know much of what is happening.

However, UI-wise, there seems to be relatively few ways (at least, discoverable ways) to search for events that are targeted to your interests, and within a certain distance from where you are. This is _exactly_ the kind of thing I expect facebook to do _well_. It has enough data on me, damn it. Yet, I find it almost impossible to get FB to actually give me a list of music events that I might enjoy that are in a given city. (And if you want to search one city over from where you are, forget it.. it's either your "home" city, or nothing.)

If I search for very specific terms, sure I can find relevant things, but it doesn't seem to be much better than text-searching a database. I'd rather it finds similarities with things my friends like, previous events I've attended, etc, and use this to recommend things to me in the new city I moved to. But no. It's like starting from scratch. Meanwhile I continue to get ads for events in the previous city I lived in, while I already told FB that I moved to a different continent.

The best approach I've found so far is to find one or two poeple/productions that do things that I like, and to start checking their friends/likes, but this feels extremely "manual". Isn't the whole point of a huge database like FB for it to figure this out for me?

</comment><comment><USER15> The article only mentions their app. I try to install as few apps as possible for personal reasons.

Their mobile web UX is turning sour, fast. (I primarily used the messenger function, so my view is very skewed the)

I don't have any strong things to point at other than the messenger function, but it just feels far worse than it did a year ago.

</comment><comment><USER16> Journalists are very good at writing a lot about things they don't understand.

<comment><USER17> Maybe, but the commenters on this post are excelling at it.

</comment></comment><comment><USER18> So instant article is good because now sites/writers will get to place ads which will not get blocked and will supposedly get more traffic for which Facebook begs you to convert into a sponsored post?

</comment><comment><USER19> "Eating the internet" sounds a bit hyperbolic in this context (instant articles) seeing as the article mentions that Google and Apple are also doing it. Or did I miss something?

<comment><USER20> The internet is also much larger than "the Web." Just some hyperbolic tech-is- king nonsense from a breathless journalist.

</comment></comment><comment><USER21> Facebook looks like something from 2005. It's outdated and has low usability.

</comment><comment><USER22> try facebook with js disabled on your phone. Feels a lot more faster and non of those annoying "Oh please or please mr, please install our app, oh please"

</comment><comment><USER23> In what world does Facebook have good UX?</comment>


Tell HN: Fill in those Profiles! - <AUTHOR>

Howdy Hackers,
After giving it some thought, I've fleshed out my profile quite a bit, almost making it into a cover letter. Reading it, you can get an idea of my experience and how it may shade my comments.
Without sounding too pretentious, I want to make my profile a sort of standard in terms of information. It is undoubtedly easier to converse civilly with someone when you know enough about them to consider them friends, and profiles provide a soapbox for an individual to broadcast this information.
So my fellow hackers, join with me and fill in those profiles! We are currently subpar, and things have to change.
-Shamiq <comment><USER2> I think there are plenty of reasons to keep your profile brief, I have made mine as verbose as I would like it, I assume plenty of people here are either anonymous or nearly so because they don't want to put other people off.

Each to his own :)</comment>


Cloning the Largest Hedge Fund in the World: Bridgewater's All Weather - <AUTHOR> https://mebfaber.com/2014/12/31/cloning-the-largest-hedge-fund-in-the-world-bridgewaters-all-weather/ <comment><USER2> Under a pure capm the market is the optimal portfolio, that you can mix with the risk free asset to get whatever risk/reward payoff you want, and multifactor approaches can replicate a lot of the returns of various funds, so not too surprising I guess that a large hedge fund approach ok mates the market very well, since the larger you get the harder it can get to find strategies that really outperform</comment>


What do you say to an alien? - <AUTHOR> http://earthspeaks.seti.org/ <comment><USER2> "The fact that you can understand this is terrifying; please don't kill us."

<comment><USER3> Is that the message they send us once we decrypt their communications?

</comment></comment><comment><USER4> Sooo what do you think? Vim or Emacs?

</comment><comment><USER5> Doesn't matter what we say, they can already read our thoughts.

<comment><USER6> Far more concerning, they've probably read the comments at YouTube or overheard the conversation that occurs on XBox Live during a round of Call of Duty.

</comment></comment><comment><USER7> What's the favorite color of the entity communicating with us?

This may seem silly, but there are a lot of interesting implications to the answer.

Does the alien have a concept of color? We learn about biology. If we know about their star and habitable zone, we can surmise a lot about not just them but their environment.

We learn something about their aesthetics. Maybe we can't understand them or they are relatable to us.

The point is, ask a question which can provide lots of other info.

<comment><USER8> Aesthetics might be more appropriate. Ascetics are likely to not care much about colors ;-)

</comment></comment><comment><USER9> Why is there an overwhelming assumption that alien life is going to be in any way more remotely intelligent than say, the average earth cockroach? I've always assumed that if we meet alien life, it's going to be smaller and dumber than humans. Perhaps I'm just pessimistic, but this seems a legitimate assumption.

<comment><USER10> Because if we meet them, it's because they _got here_ thus they're a lot more technologically advanced than we are?

(Though there's a fun short story from way back that ends with aliens who have FTL travel wanting to buy our high-reliability computing/robotics tech, because they've never developed any for themselves :-)

</comment></comment><comment><USER11> ∙ ∙ ∙∙

∙

∙∙

Hopefully said aliens are visual in nature and understand spacing.

If they do, this works also: ○

</comment><comment><USER12> ...---...

</comment><comment><USER3> One thing that struck me was how pessimistic many messages were. They were somewhere along the lines of "don't land!", "save me!", and "please save me!".

</comment><comment><USER13> _What do you say to an alien?_

"I figured you'd be an alien, babe, because your ass it out of this world".

<comment><USER3> Nerdy pickup lines never work.

<comment><USER13> Worked with every alien I've met!

<comment><USER14> I've used similar lines and had to play dodge the beer bottle. Good for you :)

<comment><USER13> OK, I'll venture more into the OT, but I think the "pickup lines don't work" misses the point.

The point is, if you are a stud and the girl is attracted to you, almost anything works, even borderline sexist stuff.

If not, then yeah, you need a lot more work that some pickup line. But it's not like they rejected you because you used a lame line.

</comment></comment></comment></comment></comment><comment><USER15> "Hello Mr. Gingrich"</comment>


Countdown Timers: Do They Increase Sales? - <AUTHOR> https://capitalandgrowth.org/questions/1477/do-countdown-timers-increase-sales.html <comment><USER2> I see "three left in stock" often on Amazon. I don't know if it is true or false but I've checked back many times days later to find the same number after I bought one.... seemingly perpetually.

A cart timer I would immediately think is disingenuous if it was for a traditional retail good.</comment>


Hacking YouTube - YouTube Bots - Hacking for noobs - <AUTHOR> http://hacking4noobs.x10.mx/hacking-youtube-for-noobs/

<comment><AUTHOR> What do you guys think of the website?</comment>


Powered exoskeleton suit HAL 5 (driven by nerve impulses) - <AUTHOR> http://en.wikipedia.org/wiki/HAL_(robot)

<comment><USER2> But does it really work? The links were all a journalism pieces about what it Could do. The one hospital study concluded the children had more fun; of course they did! They were wearing a robot suit! They didn't study if it helped them move their arms or legs, or if their walking improved, or anything.

Sounds interesting but probably just a gimmick so far.</comment>


If you don't hire juniors, you don't deserve seniors - <AUTHOR> http://isaaclyman.com/blog/posts/junior-developers/ <comment><USER2> Juniors are wonderful, but they make messes and are a training and maintenance burden on more experienced developers.

They really are like puppies, and if your org can't take care of them you shouldn't adopt one.

</comment><comment><USER3> The flipside of this story is that companies often only hire junior developers for the lower cost.

Some companies 10-15 year old companies are composed 80-90% of junior developers, and that's a problem too.</comment>


Machine Learning using JavaScript - <AUTHOR> http://burakkanber.com/blog/machine-learning-in-other-languages-introduction//

<comment><USER2> Interesting, especially to see in JavaScript. I'm not familiar with machine learning, but is there a general pattern of how ML stores its learned data? Is that a silly question?

<comment><USER3> What do you mean by learned data?</comment></comment>


Hack money out of politics: Democracy Hackathon (March 29-30 San Francisco)  - <AUTHOR> http://www.eventbrite.com/e/hack-for-democracy-registration-10711042015 <comment><USER2> The amount of influence money has on the state is directly proportional to the amount of control the state has on the economy and justice system. Money in politics wouldn't nearly matter as much if the government didn't apply heavy- handed control to every market and courtroom around the country.

As long as power is centralized into a few politicians hands, there will always be a massive concerted effort to buy that power.

Everyone who champions for more state-intervention, this is the natural side- effect you'll have to live with. Welcome to your unintended creation. Transparency is the only possibly counter-balance I could see helping the situation, but I don't see any level of transparency being added to gov operations. The trend has been in quite the opposite direction.

<comment><USER3> What justice system do you envision outside the state?

<comment><USER2> It doesn't have to exist outside of the state:

[https://en.wikipedia.org/wiki/Night- watchman_state](https://en.wikipedia.org/wiki/Night-watchman_state)

Whereas currently 86% of people in federal jail are there for victimless crimes:

[http://www.policymic.com/articles/8558/why-we-need-prison- re...](http://www.policymic.com/articles/8558/why-we-need-prison-reform- victimless-crimes-are-86-of-the-federal-prison-population)

</comment></comment></comment><comment><USER4> The problem isn't "money in politics". The problem is that the political process is too shallow, so much so that ordinary advertising can swing results often. And that is due to the electorate and the media. If you try to force money out of elections then you don't solve the underlying problems and you end up just moving corruption around, the money ends up less direct and harder to trace. Nobody wins and we end up bacck where we started.

<comment><AUTHOR> Some media reform and education reform can be imagined that would help with this problem. However, no such reform can actually be enacted while our lawmakers are dependent on their funders instead of common sense or the wishes of the people.

<comment><USER4> I think that sentiment stems from the idea that law shapes society rather than society shaping the law. The reason the media is the way it is today has more to do with societal and cultural norms than with the law. It can, and should, be changed not through laws but through society.

</comment></comment></comment><comment><AUTHOR> Hey all, unfortunately (but also fortunately), we are full up to capacity for this event. Please contact me if you are interested in other ways you can support teamdemocracy.us, or have a fantastic idea you want to hack on. My gmail is my username here.

</comment><comment> vezzy-fnord What happens when things go the other way around: [https://en.wikipedia.org/wiki/Hacking_Democracy](https://en.wikipedia.org/wiki/Hacking_Democracy)

<comment><AUTHOR> The threat to democracy from closed electronic voting systems is well documented. But why do these systems get put in place? Could it have some connection with political donations by companies that manufacture the machines, such as Diebold?

Our political system cannot reach unbiased, good decisions about what types of voting systems to implement if it's being swayed by big donors.

We have to hack to get money out of politics, so that our politics don't get hacked!

</comment></comment><comment><USER5> Since this board is full of logical people (programmers), I'm curious to know why any of them think that a system based on tyranny of the majority would increase freedom for people?

Also, I'm really curious what sort of things you all think you can "hack" that will really make people more free. After this, will the NSA be gone? How about the entire military industrial complex and all it's mouthpieces on tv and in Congress? What about the drug war and the power of big pharma? Diebold? Dynasty families like the Bush's and Clintons? Etc Etc Etc.

If any of you were serious about freedom you would be figuring out how to hire lawyers, not coders. A better voting app is just an easier way for my representatives to give me false choices.

<comment><AUTHOR> Tyranny of the majority is still better than any other system humanity has so far come up with.

Some of the suggested hacks are listed at the link. They will not, by themselves, get rid of the NSA, but they are reasonable steps that the anti- corruption movement can take at this time to raise awareness and build momentum.

You can join in and start working on the BIG problems you listed, or you can say this cannot be done and do your own idea which seems to be about hiring lawyers.</comment></comment>