The theory behind it surely is not a day to day topic, but I think the ability to know the rough time and space complexity of an algorithm you've just written is super important.
I dabbled in CS before ultimately not pursuing it in college. Not every CS concept is critical professionally, but from what I learned at the time, this is a topic that has proven to be a big part of letting me intuit solutions in my day-to-day.
It's definitely one of those topics that appears complex and mysterious until you familiarize yourself enough with it to realize that it's basically just a notation for eye-balling the relative growth patterns and performance of comparable algorithms.
Regular Expressions! With all the esoteric differences due to dialects, multiple platforms, multiple languages; I have refused to co-opt my brainspace with them. They are beautiful and powerful. They are awesome. I will never learn them. When I need them, I need a book, a google or a friend.
Understanding finite state machines, whether you are the consummate computer scientist who remembers that term from her first course in discrete mathematics or the self-taught hacker who gets the idea by slogging through a regex reference, is a fundamental tool for applying logic to data. Actually understanding them is more important than being able to search Google, find a book or ask a friend because not all regex solutions to a given problem are created equal. Any monkey can paste in a handful of passable expressions, glued together with bloated, unsightly, difficult to work with code, that does unnecessary data transformations and I/O to compensate. But someone who knows regex well can often write a single, svelt expression that speeds through all of that. Especially when you're dealing with big data, the cycles and the I/O start to add up. I'd be much happier to find a complex regex in someone else's code, with a concise but poignant comment, rather than an extra fifty lines of unnecessary loops and string manipulations.
I always ask a fairly complicated regex question during interview. You probably shouldn't apply for the open position at my workplace ;)
Complicated regex during the interview is no different than complicated code during the interview. It doesn't prove anything because we have tools like IDE and search. I could come up with my own esoteric reasons for wanting someone to be deep in binary logic, or know exactly how DNS works. but at the end of the day these are tools. If someone is aware of the various tools and can use them enough to accomplish the tasks, then really, that is enough. All I want in a recruit is the passion for learning, I don't care if they know any regex, as long as they are willing to learn.
I agree, but not across the board. When I do ask a technical, test-like question during an interview, I expressly refrain from trying to trick or find the limits of a candidates knowledge. While there is a component of wanting to make sure he or she is not lying to me about some skill listed on the resume, and I certainly would be glad to see that the candidate can competently solve the problem, I'm most interested in seeing if he or she can get stuck and ask for help. Anyone who can admit not knowing, and rather than give up with an "I don't know" but instead seek to still accomplish a goal by asking for help in an interview will pique my interest, not only for displaying an excellent work ethic, but also giving me the chance to travel through his or her problem solving and thought process. You want to hire for an entry level devops position, sure, no test questions, and focus on that passion for learning. You want to fill a senior or supervising devops position, that person must be intimately familiar with regex because she will be the person teaching the willing entry level guy.
Yeah, totally get that if you are hiring a senior position then knowing the common tools is a requirement. You are hiring a master of their craft, not a journeyman. I took your original post to mean you do that for all hires :)
I'm pretty familiar with regex concepts and basic usage from a course I took in Perl, but it seems like every time I use them in a program my knowledge is obscured by the various discrepancies between languages.
Don't worry, if you don't go to function programming, it will come to you. Most languages support and increasing number of functional constructs. They are very useful, and you might already know them.
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
Assembly language. It's still on my bucket list, but unless I start doing, say, serious reverse engineering, I probably won't have a good professional reason to need to know it.
You might be surprised at how straight-forward it is to understand. If you have a decent understanding of how memory, addresses, and code flow works you should be able to understand assembly.
You wouldn't likely ever write asm code, though there are several IR (intermediate representation) levels that are around now. In compilers we mainly work at the IR level now for the low-level stuff. Sure, somebody has to emit actual machine code at some point, but I've never felt the need to go that low, and I actually work on a compiler.
I'll look from a different angle. Do we need formal education in any programming concept to learn them?
SOLID principles, BigO notation, Docker and frenemies, functional programming, traits (PHP), most class inheritance stuff, schemaless structures (was in Pascal Records in the 90s), recursion.
I knew and was using them before I knew their names (except Docker&fr, we used to call them virtual hosts back in the day ;). Never really studied any of them, and I realized I already knew them when I studies them.
I'm a teacher and I know for a fact that it is better to not name concepts and structures until the pupil learns them by heart. And at that point, studying the concept becomes useless because the pupil is already aware of things. This doesn't apply to university level conscious studies of course.
So much this. As a self fought developer I know almost none of the names of the principles implemented in my work and I've been doing it for 18 years now.
This is a tricky question in programming. When all I knew was Applesoft BASIC, I never missed recursion. Before learning Smalltalk, object orientation seemed to be overkill. Before understanding FP, things like partial invocation or lazy execution seemed like distant theoretical constructs of little or no actual utility.
To put it shortly, you don't miss what you don't understand.
This one is interesting to me because there are things I wish I didn't have to know that I have had to know.
But here's the list of things I have never had to worry about (9 years):
Relational databases
CSS
Assembler
And for the things I have had to use:
Regular expressions
Big O
Trees/Graphs
Big/Little Endian
64 vs 32-bit programming
Threading... THREADING!
JVM tuning
Manual memory management
Now I'm sharing this list because I personally think the software industry is converging on web development. There is actually a huge world out there beyond web development where some of these more esoteric seeming things have mattered.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Advanced CSS and DOM manipulation, but that's mostly a function of having specialized in backend development.
Formal lambda calculus: I know some of the basic ideas and I've worked with closures and other functional concepts enough to understand the direction it's headed but I've never bothered to go all the way in on it.
In-depth knowledge of lots of basic CS algorithms and data structures: I know enough to know that if I ever have a problem best solved by (for example) a red-black tree, I'll be able to work out that I need a binary search tree of some sort, evaluate my options, and settle on the optimal approach. That doesn't require a deep understanding of red-black trees right now and from here it seems unlikely I'll ever need one, so until the situation changes it can stay a "known unknown" per Rumsfeld. That said, I did wind up writing my own Set extensions and Digraph a while back, so this kind of thing has happened!
I have never been able to do anything concrete with logarithms. I have a simultaneously complex and vague impression of what they are (something something exponent something switch places around something curve that looks appropriately reversed from an exponential function) and what they might describe (logarithmic time = better than) but dear god don't ask me to actually put them to work.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Machine learning and big data are the two things that I have spent 0 time learning, yet I've been doing just fine without. I have a sneaking suspicion that this will change in a matter of many years though.
I haven't spent a lot of time working on hardware development. I'm a strong believer that whether your are creating a website or a database, that an understanding of computers from hardware to interface is required. That said, I haven't picked up a soldering iron before.
Most of the stuff I memorised at the time to try to pass interviews at Google. I didn't make it through on site interviews but I have been fine nonetheless :-D
They basically tell you that the interviews are about anything (also I was interviewing for SRE, which is not actually what I wanted to work at): from math to all the algorithms to all the data structures to system design to software design.
I spent weeks preparing and memorising obscure tree implementations, it felt like being in school all over again and I eventually forgot most of it. Maybe except how graph theory is the coolest :D
I did learn these but never really needed them. Would be a bit rusty on some.
pointers - because of managed languages / pass by ref semantics
sort algorithms - languages I used already had them
TDD and Test First - tried it for a while
AOP (aspect oriented programming) if anyone still remembers it
dependency injection containers - It’s a statically-typed language thing, but not really needed there either.
tree structures: b, b+, avl, etc. Languages / databases already had specific collections / indexes which implement these under the covers. Fascinating to know for performance characteristics tho.
bloom filter
actor model of computation
agent based programming - tried, but message passing overhead was too slow for my workload
Never actually put any of this into a production project except TDD. Have used other framework’s DI containers when they force it on me, but not my own.
Don’t get me wrong, over time I have learned a lot of low level details like: heap vs stack allocations, big-o of various collection operations, avoiding cache misses, flushing registers to memory, etc. Because managed languages are still leaky abstractions over the hardware they run on, I’ve bumped into some weird edges that caused me to learn it.
NoSQL; honestly, it's a document store, cool. SQL (esp. Postgres/Maria) can do it as well. Checkout how Wordpress / every CMS stores user profile field names and values.
Not knowing there was this AWS Function Step and instead, i have a fat function orchestrating what other lambda to call and when. But im alright with it (for now)
I am interested in clean code, clean architecture, cyber security and blockchain.
I can talk English, Spanish and French. Looking for some inspiration. Love bikes.
Algorithm complexity things (i.e Big O)
The theory behind it surely is not a day to day topic, but I think the ability to know the rough time and space complexity of an algorithm you've just written is super important.
I dabbled in CS before ultimately not pursuing it in college. Not every CS concept is critical professionally, but from what I learned at the time, this is a topic that has proven to be a big part of letting me intuit solutions in my day-to-day.
It's definitely important, I just couldn't understand how to do it. But, I will learn it one day :)
It's definitely one of those topics that appears complex and mysterious until you familiarize yourself enough with it to realize that it's basically just a notation for eye-balling the relative growth patterns and performance of comparable algorithms.
You might like Complexity theory isn’t required to be a programmer
Container orchestration
Still need to figure that out lol
Regular Expressions! With all the esoteric differences due to dialects, multiple platforms, multiple languages; I have refused to co-opt my brainspace with them. They are beautiful and powerful. They are awesome. I will never learn them. When I need them, I need a book, a google or a friend.
Understanding finite state machines, whether you are the consummate computer scientist who remembers that term from her first course in discrete mathematics or the self-taught hacker who gets the idea by slogging through a regex reference, is a fundamental tool for applying logic to data. Actually understanding them is more important than being able to search Google, find a book or ask a friend because not all regex solutions to a given problem are created equal. Any monkey can paste in a handful of passable expressions, glued together with bloated, unsightly, difficult to work with code, that does unnecessary data transformations and I/O to compensate. But someone who knows regex well can often write a single, svelt expression that speeds through all of that. Especially when you're dealing with big data, the cycles and the I/O start to add up. I'd be much happier to find a complex regex in someone else's code, with a concise but poignant comment, rather than an extra fifty lines of unnecessary loops and string manipulations.
I always ask a fairly complicated regex question during interview. You probably shouldn't apply for the open position at my workplace ;)
Complicated regex during the interview is no different than complicated code during the interview. It doesn't prove anything because we have tools like IDE and search. I could come up with my own esoteric reasons for wanting someone to be deep in binary logic, or know exactly how DNS works. but at the end of the day these are tools. If someone is aware of the various tools and can use them enough to accomplish the tasks, then really, that is enough. All I want in a recruit is the passion for learning, I don't care if they know any regex, as long as they are willing to learn.
I agree, but not across the board. When I do ask a technical, test-like question during an interview, I expressly refrain from trying to trick or find the limits of a candidates knowledge. While there is a component of wanting to make sure he or she is not lying to me about some skill listed on the resume, and I certainly would be glad to see that the candidate can competently solve the problem, I'm most interested in seeing if he or she can get stuck and ask for help. Anyone who can admit not knowing, and rather than give up with an "I don't know" but instead seek to still accomplish a goal by asking for help in an interview will pique my interest, not only for displaying an excellent work ethic, but also giving me the chance to travel through his or her problem solving and thought process. You want to hire for an entry level devops position, sure, no test questions, and focus on that passion for learning. You want to fill a senior or supervising devops position, that person must be intimately familiar with regex because she will be the person teaching the willing entry level guy.
Yeah, totally get that if you are hiring a senior position then knowing the common tools is a requirement. You are hiring a master of their craft, not a journeyman. I took your original post to mean you do that for all hires :)
Definitely sounds like one I'll avoid, thanks!
I'm pretty familiar with regex concepts and basic usage from a course I took in Perl, but it seems like every time I use them in a program my knowledge is obscured by the various discrepancies between languages.
Oh boy, these will all go straight into my interview questions for senior developers. :D
OOP in JavaScript
What I really like about OOP is that you can write your code in a super declarative way. It almost becomes english.
car = new Car
car.drive
car.onCrash {
insurance.collect
}
etc :)
Functional programming languages and machine learning, especially all the math related stuff
but the tide may change... And hopefully when there is a need for it, the math won't be as intimidating. What about you Ben?
Don't worry, if you don't go to function programming, it will come to you. Most languages support and increasing number of functional constructs. They are very useful, and you might already know them.
UML modelling. It was going to be "THE THING" in the late 90s. I took a look at it and couldn't figure out how to make it work for my projects.
By the look of things 20 years later, neither could anybody else.
Assembly language. It's still on my bucket list, but unless I start doing, say, serious reverse engineering, I probably won't have a good professional reason to need to know it.
You might be surprised at how straight-forward it is to understand. If you have a decent understanding of how memory, addresses, and code flow works you should be able to understand assembly.
You wouldn't likely ever write asm code, though there are several IR (intermediate representation) levels that are around now. In compilers we mainly work at the IR level now for the low-level stuff. Sure, somebody has to emit actual machine code at some point, but I've never felt the need to go that low, and I actually work on a compiler.
That link gives a big red security warning from Chrome that the connection isn't private.
Accidentally made a https link, that site doesn't support SSL quite yet. Updated.
Pick up an Arduino and make lights blink. Simple hardware fun! :)
I'll look from a different angle. Do we need formal education in any programming concept to learn them?
SOLID principles, BigO notation, Docker and frenemies, functional programming, traits (PHP), most class inheritance stuff, schemaless structures (was in Pascal Records in the 90s), recursion.
I knew and was using them before I knew their names (except Docker&fr, we used to call them virtual hosts back in the day ;). Never really studied any of them, and I realized I already knew them when I studies them.
I'm a teacher and I know for a fact that it is better to not name concepts and structures until the pupil learns them by heart. And at that point, studying the concept becomes useless because the pupil is already aware of things. This doesn't apply to university level conscious studies of course.
So much this. As a self fought developer I know almost none of the names of the principles implemented in my work and I've been doing it for 18 years now.
This is a tricky question in programming. When all I knew was Applesoft BASIC, I never missed recursion. Before learning Smalltalk, object orientation seemed to be overkill. Before understanding FP, things like partial invocation or lazy execution seemed like distant theoretical constructs of little or no actual utility.
To put it shortly, you don't miss what you don't understand.
This one is interesting to me because there are things I wish I didn't have to know that I have had to know.
But here's the list of things I have never had to worry about (9 years):
And for the things I have had to use:
Now I'm sharing this list because I personally think the software industry is converging on web development. There is actually a huge world out there beyond web development where some of these more esoteric seeming things have mattered.
My CSS knowledge is outdated / flaky. I do most of my work on API's or backend stuff.
Bootstrap is a nice crutch to make things decent looking.
So in my daily job it's not really a problem but it would be more fun I had a better understanding of modern CSS.
Advanced CSS and DOM manipulation, but that's mostly a function of having specialized in backend development.
Formal lambda calculus: I know some of the basic ideas and I've worked with closures and other functional concepts enough to understand the direction it's headed but I've never bothered to go all the way in on it.
In-depth knowledge of lots of basic CS algorithms and data structures: I know enough to know that if I ever have a problem best solved by (for example) a red-black tree, I'll be able to work out that I need a binary search tree of some sort, evaluate my options, and settle on the optimal approach. That doesn't require a deep understanding of red-black trees right now and from here it seems unlikely I'll ever need one, so until the situation changes it can stay a "known unknown" per Rumsfeld. That said, I did wind up writing my own Set extensions and Digraph a while back, so this kind of thing has happened!
I have never been able to do anything concrete with logarithms. I have a simultaneously complex and vague impression of what they are (something something exponent something switch places around something curve that looks appropriately reversed from an exponential function) and what they might describe (logarithmic time = better than) but dear god don't ask me to actually put them to work.
Office politics
Machine learning and big data are the two things that I have spent 0 time learning, yet I've been doing just fine without. I have a sneaking suspicion that this will change in a matter of many years though.
I haven't spent a lot of time working on hardware development. I'm a strong believer that whether your are creating a website or a database, that an understanding of computers from hardware to interface is required. That said, I haven't picked up a soldering iron before.
Example:
youtube.com/watch?v=xISG4nGTQYE
Most of the stuff I memorised at the time to try to pass interviews at Google. I didn't make it through on site interviews but I have been fine nonetheless :-D
They basically tell you that the interviews are about anything (also I was interviewing for SRE, which is not actually what I wanted to work at): from math to all the algorithms to all the data structures to system design to software design.
I spent weeks preparing and memorising obscure tree implementations, it felt like being in school all over again and I eventually forgot most of it. Maybe except how graph theory is the coolest :D
I did learn these but never really needed them. Would be a bit rusty on some.
Never actually put any of this into a production project except TDD. Have used other framework’s DI containers when they force it on me, but not my own.
Don’t get me wrong, over time I have learned a lot of low level details like: heap vs stack allocations, big-o of various collection operations, avoiding cache misses, flushing registers to memory, etc. Because managed languages are still leaky abstractions over the hardware they run on, I’ve bumped into some weird edges that caused me to learn it.
Regex
Advanced CSS and making things look pretty.
OOP :P
NoSQL; honestly, it's a document store, cool. SQL (esp. Postgres/Maria) can do it as well. Checkout how Wordpress / every CMS stores user profile field names and values.
Making (big) money.
The heap and the stack.
Not knowing there was this AWS Function Step and instead, i have a fat function orchestrating what other lambda to call and when. But im alright with it (for now)
business administration
Most of the patterns.