Hacker News Reader

Comment by bluejekyll | Hacker News Reader

> Being a software engineer is about way more than just knowing what algorithm to apply to solve a clearly-stated problem.

Actually I think this is exactly what a software engineer is. Knowing what datastructure to use in which situation because of its implementation details is important! Yes, it's not the only aspect of the job, but it's hugely important.

It can be as simple as Arrays vs. LinkedLists; where Arrays have zero cost access and LinkedLists have high indexing costs, but low constant time insertion costs where you don't know the content length. This can have huge effects on the performance of an application.

This is important to applications, and no, you don't have to implement the datastructure, but knowing which to use when and why can save you the time later from having to find all your performance problems.

View on HN

I was interning at a pretty successful software company in The Netherlands. I have never heard anyone there discuss about whether to use Arrays or LinkedLists.

In the binary education system in The Netherlands there are two types of universities, that which prepare people for industry jobs and that which prepare people for research. I went to both, the former has only a small focus on algorithms, complexity and datastructures. The latter has specific courses about those topics.

I think in practice you can often reach good enough performance without worrying about which algorithm or datastructure to use or what the complexity of your code is. There are many exceptions where those kind of skills are actually required, but it's easy to forget that software is a huge market and that a large portion of that market is people developing fairly uncomplicated applications.

You can create an incredible amount of value in the software industry without knowing much of computer science, but you are dependent on people who actually have that knowledge to create your tools, dependent libraries, used services, etc.

Sounds familiar. I had only the former kind of education. Often I'm pondering if I should pursue a masters degree in anything CS related. It's not that I really need it for my work. So, my options are to either do a CS master, and have to catch up on a lot of math and CS fundamentals, do some master in a totally different field such as business administration (useful since I have my own company), or do nothing at all :). Any advice from your perspective about this?

I loved my time studying for a masters degree, and after graduating I started with a PhD in Japan which has been an amazing experience. If you want to learn many new things, meet interesting people from all over the world and you don't mind going back to taking classes I would definitely recommend it. Don't worry too much about the math and CS fundamentals. The stuff you need to know to do a master's in CS is quite useful in practice, so it's valuable to learn about that anyway. Some specialisations in CS require more math than others, so keep that in mind.

If you don't know whether to do CS or business administration, you might be able to do something in between, e.g. business administration with a IT specialisation.

(I got master degrees in Computer Science and Business Information Technology from the University of Twente and am currently a PhD student in Empowerment Informatics at the University of Tsukuba in Japan)

You're making an assumption that "performance problems" are important. Sometimes they are. Often times they simply aren't. In my experience, outside of certain components of a game engine, scientific/numerical computing, very large (e.g. Google scale) systems and a certain class of real-time systems the difference in performance between one data structure and algorithms that operate on it or another simply isn't worth worrying about.

It's far more important that the code be simple, readable, and integrate easily with other teams' work.

You left out a really big, significant sector: finance. Minimal latency is king (at least in trading). This often means little or no heap allocation (if there is any, it's often done up-front). User-space network stacks to avoid the user to kernel context switches. Web devs think that sub 10ms response time are good. In finance, often anything over 10 nanosecs (for example when responding to an IOI - indication of interest) is trash.

Yeah, sure, in some domains latency isn't terribly important, but there certainly are a number of domains where it is.

Yes, we are in agreement (except for what I perceive as a derision toward "web devs", which by the way I am not and didn't even mention, so I'm not sure why you even mentioned it). I also left out specific kinds of some very resource constrained domains in general; a terrible omission on my part. I'm sure there are others as well that I didn't call out specifically. Not having experienced every single kind of programming problem type I rather think it would be silly and pretentious of me to try to enumerate them all.

> except for what I perceive as a derision toward "web devs", which by the way I am not and didn't even mention, so I'm not sure why you even mentioned it

I didn't read it as derision. I read it as an indication of a different focus between two areas of development. Microseconds don't matter in most cases. Milliseconds matter more often. Something optimized for microsecond-ish timing will make a tradeoff somewhere else (like code readability, generalness, etc).

often anything over 10 nanosecs is trash

Are you sure you don't mean 10 microseconds?

He probably means 10 microseconds, even if he's talking about HFT. The state of the art for FPGA's seems to be around 700 nanoseconds. [0]

[0] http://stackoverflow.com/questions/17256040/how-fast-is-stat...

Sometimes you have to wonder how much we are suffering "death by a thousand cuts" though. This is still quite noticeable on mobile and in certain applications.

>It can be as simple as Arrays vs. LinkedLists; where Arrays have zero cost access and LinkedLists have high indexing costs, but low constant time insertion costs where you don't know the content length.

But then in the real world, arrays can still be faster than lists even when you're inserting a lot...

https://www.youtube.com/watch?v=YQs6IC-vgmo

Yes, if you can afford the allocation of the memory upfront Arrays are always faster :)

My point was more that understanding the semantics of the two types is important to how the program will run.

Reply on news.ycombinator.com