Let's say you never really learn regex. You know how and when to use it, but you never quite get past needing tools and search engines.
Is that okay? Is it necessary to advance past this point? Why or why not?
Let's say you never really learn regex. You know how and when to use it, but you never quite get past needing tools and search engines.
Is that okay? Is it necessary to advance past this point? Why or why not?
For further actions, you may consider blocking this person and/or reporting abuse
In a previous job, there was a regex wizard. Things were good. He was wise. We could go to him, present him with a problem, and he would write a solution on some yarn (Slack).
A short while after he left, I found myself with a problem that regex could solve. I was left with Google. So I hacked. I copied and pasted and used the regex-helper websites as I ran around the china shop that is string parsing, smashing everything as I went.
I didn't know it at the time but when I searched and hacked a solution together, I was learning bits and bobs. Stray phrases of advice stuck me with. Occasionally and without knowing it I would find myself on a tech blog explaining the intricacies of search patterns.
Then one day someone who had seen some of my diffs approached me and requested a regex solution. Without knowing it I had become the wizard. An expert who knew almost nothing.
It would have been quicker just to learn the theory from the start! 😊
Take the problem as an oportunity to learn, to explore and prove to yourself that isn't "magic" and you can be the "wizard" too...
This is how I feel a huge amount of engineering seniority develops. It comes in small spurts and builds up over years, frequently we don't even realize how much we know.
I jump between languages a lot. I have to Google the most rudimentary things all the time. For the most part, I know what I need to do and how to do it, but remembering the exact function names and syntax for all the languages, libraries and frameworks I use is impossible.
I also strongly agree with what you have said. Its impossible to remember or memorize A-Z all the time about any thing.
Yeah, I find myself searching for standard library stuff all the time when I swap languages.
It's good to know how they work, but sometimes you get method or function names mixed up in your head.
I believe there is nothing like "never really learn".
There is just "no enough motivation".
I realized that when I was asked to explain regex to validate data in the frontend for new comers.
I couldn't stand the idea of explaining "poorly" in front of many people, so I looked up regex thoroughly to avoid any embarrassing situation.
That was my enough motivation to learn regex, and I reflect this story to any "never able to learn" situation as "no enough motivation".
There are a lot of very good comments on this post. I think many can be summed up as you should learn what you use frequently but that it's okay to have a broad and shallow appreciation of many topics that you can google. Turning that around you should understand and gain expertise in the things you use every day.
My grandfather told me that you are not paying a teacher to make chalk marks on the blackboard. You are paying them for what they know and their skill in explaining it. Knowing what to google is a similar situation. One big difference between a programmer who is struggling to get started and one who can be thrown any task is knowing just enough to google.
A couple of decades ago you needed to read the right books. Until google and stackoverflow you needed to read the right websites and forums. More recently to get up to speed on some new tech you need to watch the right YouTube channels.
I would suggest if anyone finds themselves googling too often for something they should watch a few videos about it. I recommend using a player that lets you speed up the playback to as fast as you can comprehend then skip back and slow down anything you missed. Some techs will always require deep knowledge, for example cryptography, but mainstream technology competes for mindshare by being accessible. After a bit of video research you can google like a boss and with a bit of experience you can be highly proficient in most mainstream tech.
I think it's a great place to start with anything. If you need something frequently enough, you'll start to remember it.
So for example, I'm quite new to Elixir, and the backend at my job is written in it. I went through most of the getting started guide quite quickly, and then dove into the code base. The basics of defining modules and functions stuck quite quickly, but I still need to google for things like
caseandcondstatements, and standard library functions.I think where actively learning things by following tutorials works best is for unknown unknowns. You might not know that a particular type of solution is out there, so you don't know to Google for it.
Everyone searches for syntax from time to time!
I like your point about determining unknown unknowns with tutorials.
I am usually against Regex in general, things can get quite out of hand if one doesn't fully understand how it works and use it, especially if it passes tests (covering happy paths) and reaches production 😱.
But to answer the question, I personally have been in situations where I needed to Google to find something which was close enough to what I needed and then used a couple of online regex checkers to validate what I was writing. And I am one of those who believe it's really rare that you know everything about a topic. So even if I feel confident, I always do a bit more research (Google, find someone expert, use a tool, etc) ¯_(ツ)_/¯
Regex is a powerful tool, but as every Tobey Maguire fan knows: With great power, comes great responsibility.
It took me a full 2 minutes to understand the title. LOL
Seriously now, I keep my own personal documentation for everything I study. Taking notes on everything is a great way to remember it, so I rarely actually go through them; but as it's organized the way I understand it, it's easier to find what I'm looking for. Otherwise, I use DuckDuckGo :D
DuckDuckGo users unite!
There are literally dozens of us!
Let’s turn that into hundreds 😄
We need software to help us write software for the same reasons people need the software we write. We write the software so that it can do for someone what they would do manually or store whatever they would remember. Google, in turn, stores the details we would otherwise have to remember in order to build such software. We remember what to Google or use bookmarks or other software to remember what we Googled for us. I suppose at some point we have to actually remember something, but why clutter our heads with stuff we can store on someone else's shelf?
My level of knowledge with regexes is likely much higher than most peoples'. I'm a Perl guy, and this is one of the things that sets Perl apart.
I know that there's mechanisms commenting within Perl regexes (but not, if I understand, Perl Compatable Regular Expressions (PCRE), which is what other languages import). I have decided that if your regex is that far along, your problem domain has become too complex. You might be trying to parse HTML or something.
But beyond that, much simpler regexes have buggy behavior, including this lightning talk from a year ago, where a friend explains an issue with the regex engine that I kinda understand as I listen, but forget soon after the video ends.
So, while I have drank deeply from the kool-aid, I understand those who might just sip.
To put it another way, Larry Wall (the person who committed the code with the regex bug) says it's okay to speak Baby Perl, and so, who am I to say that speaking Baby Regex is a problem?
Regex is a difficult thing to say you master because, depending on the DSL, different characters are interpreted differently. I would say you never get past needing tools in this scenario because it probably isn't something your day-to-day work requires. And that's true for anything someone would decide to google.
Even if I felt totally confident in my regex, I'd still check it online.
You ask different things. I understand regex and how it works but I still double check my patterns with regexr or regex101 and sometimes googling some syntax. It is perfectly alright to know the why and google the how, imho :)
I keep lots of notes. Some of which I host to host to the public in the short future. So I always have detailed notes on how some random protocol works, what I learned the hard way about an exception, etc.
There are situations where Google isn't available. If you have sysadmin duties, and the Internet fails and chaos ensues, you may need to at least know enough console-fu to assign yourself a static IP address, set up static routes to the gateway, and proceed from there.
When part of my job was field technician, Google was sometimes an option, sometimes not. I do not inspire public confidence when I have a traffic cabinet open at an intersection and I am sitting there Googling "how to connect conflict monitor unit." If I was running wires, I was always terrified of touching my phone because I wanted to stay safely grounded to the cabinet.
Also, at some point you realize that you don't need any credentials to post things on the Internet. There are blog posts I read and I want to reach out to the author urgently and beg them to remove this from their code before something bad happens...but sometimes people need to learn the hard way (assuming lives are not at risk or it's a security thing).
99% of the content I make is intended to work like a journal. I'm writing to remind myself of things or try to process my thoughts.
I think it depends on how often you use something. I’ll be honest regex was on my to-learn for bloody ages, I even attempted to learn it a couple months ago. As I use regex very rarely I’ve already forgotten what I’d learnt, so google is my answer. If I was, however, using regex on a daily basis I’m sure I’d have a much better understanding of it. So yeah, google is good enough for me 😁
I think even if it is for a one time usage, it is important to understand what the portion of code is doing. Taking the example of regex, you don't need to learn regex but understand what the code is doing is important. Also when the usage become recurrent, I think investing some time learning it is better.
Regex knowledge is a nice-to-have.
We can't learn everything, and that means you have to prioritize your time and make smart decisions about what you put on your plate to study.
Knowing when to use one and when not to use a regex is far more valuable than memorizing the slightly obtuse syntax.
If you find yourself googling regex over and over, using them more and more, maybe then it's time to sharpen up your regex skills and dive deeper.
Otherwise I think it's fine to have to google the things you rarely use, or even keep a cheat-sheet for the syntax at hand. There's no harm in reference material.
You have one problem to solve. You use regex. You now have two problems to solve
Jokes aside, regex is powerful. I Google and hack just enough to get my job done without really getting to understand how it works. It's an art form, just not for me
I think it's important to understand the why but not necessarily memorize every single method parameter for example. Always Google, but try to understand why the solution is the solution. That way you build up the knowledge and awesomeness.
I think the depth of your knowledge should be proportional to the frequency and quality of how you use a particular thing. And quite often, it naturally follows that trend.
Let's say for example regex. I know the basics so that as I use the easiest cases almost daily, I get by. As soon as I need anything more complex (and have decided that regex is the best way to go), I google, add tests, use different online regex platforms.
Every time I go deeper, I end up learning a bit more. So my circle of knowledge extends. But would I spend weeks or months or years to truly master regex by heart? No.
One thing that better understanding of the topic does, is that it makes you a better googler. If I have no idea about regex, I can only search for very generic stuff. If I know I want to do backtracking (and I know the term), I can be more efficient in finding the right information.
I would say it's good enough when you're completing a significant portion of your code without the aid of online searches.
Or if you can at least describe the solution you're looking for but just need help with putting the words together, so to speak.
In many cases, Google/SO is just the quickest and most practical way to get stuff done fast. But, you shouldn't copy/paste an answer without having at least some basic understanding of what it's doing.
The situation where I use Google, SO and Github issues the most is for troubleshooting - when some obscure error pops up. In that case it's often the fastest way to solve a problem - this isn't about 'learning' something but about bugs in software that others have already solved or worked around, and I don't want to spend my time debugging through all of (it if that's even possible).
I know there are many "purists" who are against any form of Googling or copy/paste from SO, and who say you should learn everything from first principles and read the docs from begin to end (and solve problems by starting up your debugger), but I think that's rather out of touch and a bit elitist, there's just not enough time to go that route.
(but should you know about the general principles of web dev and the tools you're using? yes by all means)
I think it ultimately depends on how often you use what you're Googling. I don't think, outside of school, it's problematic to Google stuff, but if you end up googling the same thing every day, than it's probably better to sit down and learn the fundamentals and save yourself the time.
I wish some of my coworkers were more google-savvy. They ask me lots of computer-ish questions. I dump their questions word for word into google and get an answer in seconds. Why not save us both the time, and Google First, ask me later?
There are some things like are really basic to someone's profession. Example to an UI developer knowing flexbox or grid for example is a must for another kind of developer, knowing, map, filter and reduce really well is a must.
So based on your area of expertise you are required to learn those that are the basics of your profession.
So ofcurse everyone will go on and search stuff on google but if things are not learned search after search it means something probably is not okay.
Well, in the specific case of regex I think you should learn them well. They are a very powerful tool, intimidating maybe at first (but not so much, let's be honest...), but it can be very useful once you master it, especially if you work in languages like Ruby or Python: you can parse a structured text file in a handful of lines.
In general, I do not consider Google-based programming good enough. I see the usage of Google acceptable in few cases
In a more general case, you should have a good knowledge of your tools, so that you could use them with no Internet connection, maybe with the help of a printed manual.
I think as a programmer one of the most important things is to know that something exists not the details of exactly how to do it
In the regex example, I think it's more important to know the basic regex concepts than the exact syntax for each one, like say knowing that regex enables you to set capturing and non-capturing groups than knowing the exact syntax to do it
I mean sure, knowing the exact syntax will be faster, but if you know the concepts then you can probably search for it in a few seconds and get to the answer which is fast enough for most cases in my opinion
I agree with this! I think it's more important to know it's out there, what to use that specific thing for and know where to find it in case you need it.
That's totally fine as long as you don't profess to be a regex expert. 😉
I write a lot of Bash, but I also end up searching for tons of the "Bash-isms" that I'm not familiar with.
If I'm still writing lots of Bash in a few years, I would expect myself to stop using search as a crutch. In the meantime, it gets the job done!
I don't think it's necessarily necessary to advance beyond this point. To be honest, I still don't know a lot of regex of the top of my head. In fact I don't know many languages off the top of my head. I know what I use day to day, but I don't know every part of that language even, just what I use frequently.
What I do know is theory though and also how to look at Javadocs and Stack Overflow. Personally I'd rather keep in my brain things both in and out of work that I will need constantly, and then refer to the things I use once in a while.
Does that make me any less a developer? No I don't think so.
Also, although search engines didn't exist in the early days, huge 600 page manuals did. And often what separated good developers from great ones was your ability to know where to search that 600 page manual for your problem!! Some people got super efficient and created libraries with these snippets for their use!
The mechanism hasn't really changed, but the tech has, imho.
IMO, learn key concepts and techniques, as well as generally where to look to achieve a particular thing, and don't worry so much about committing every little detail to memory. Chances are if you're having to do the detailed parts often enough, you'll commit some important pieces here and there anyway. And if you don't, then maybe they're not that useful to know from your head.
In the regex example, I almost always use a tool to construct really complicated expressions, but I've been writing more of them lately and occasionally surprise myself by putting expressions together that I would have been terrified of a few short months ago. If I were writing a parser or something, chances are I'd learn and commit even more, but I haven't had a great reason to use a ton of regex up until recently so it wasn't as valuable of a skill to me.
Great question, Ben!
Not sure what everyone else thinks, but this question strikes me as a sub-set of the problem of code re-use. We're basically talking about code re-use via code samples online (re-using the ideas or possibly copy/pasting code).
Four questions you could ask:
1) Is the functionality core or non-core?
Some functionality is so core to the business and the product you're trying to build that it's essential that you have a strong guarantee that it will work correctly. One good way to get such a guarantee is to write the code yourself. That way you will understand it thoroughly and be able to verify that it works correctly. This will require strong knowledge of both the domain area and the coding tools/language. You can still get use out of tools and code samples, but those are for convenience, not something you should be relying on.
On the other hand, some functionality is less core. It is general to many other businesses or products and not specific to yours. This means that many businesses probably have had a similar need in the past, and have converged on a few or one optimal solution that covers all bases. In this case, it's better to harness the "wisdom of crowds" and use the solution that's already been given, rather than waste a lot of valuable time "re-inventing the wheel".
If you're doing some very particular, domain-specific and complex kind of string manipulation or comparison, perhaps you're better off modelling the problem using object-oriented and/or functional techniques, and producing string input/output at the endpoints, rather than using a regular expression.
2) Is the functionality cutting-edge or mature?
This is very similar to question 1. Basically, are you the first (or more likely, one of the first) developers to build this kind of thing? Or is this a problem that's been around for a long time, for which a mature solution has developed over time?
For example, the problem of adding or subtracting days from a date to get a new date is by no means new. At the same time, it's non-trivial to implement. There is enough nuance to the problem that it would take significant effort to solve. But because it's been a problem for so long, many mature solutions to the problem have emerged, embodied in libraries and code samples. It makes sense to re-use a mature solution to this problem, which takes into account all the nuances and gotchas, rather than go through all that problem solving on my own.
On the other hand if you're working in a scientific setting, perhaps trying to apply a new machine learning technique to a new kind of data-set, perhaps you need to be one of the early contributors to a general solution. Rather than (or in addition to) standing on the shoulders of others, you have to support others on your shoulders. Then you want to understand the whole thing very thoroughly, rather than rely on code samples. That understanding could take years of research to develop!
3) Is the feature time-critical or correctness-critical?
If, in your business scenario, it's more important that you just get the feature out quickly than with perfect correctness, then copy/pasting and using tools is the way to go. Even if there are bugs or maintainability in the future, you will (hopefully) still have a running, profit-generating business and address them as they occur.
Whereas if you spend so much time trying to get the product perfect and end up being unable to sustain enough of a pace as to get the business to a profitable level, then that extra effort ends up being a waste. You would have been better off going fast and making a few minor mistakes that can be fixed later.
On the flip-side, if you already have a solid, profitable business and what matter is correctness, then the extra time invested is a kind of insurance against bugs that could undermine the business. You want to invest the time and effort to understand the code well and write it yourself, thus protect the business.
4) Is the code at a level of abstraction that matters to you?
Some parts of the software you build are core and some parts are peripheral. Some things you need to know the details of practically by heart in order to do you job correctly, other things you only incidentally need to know of and you just learn what you need to implement them then move on.
For example, most developers don't know the internal construction of Git. I mean how the source-code of Git actually works. It's enough for them to know the command-line interface to Git, including not just the commands, but what they do and how they work together.
But developers do (or should) know a lot about the internal construction of their own code, including the patterns and algorithms embedded in that code. For example, they should be able to identify a Factory pattern in their own code and use it correctly, or identify a recursive function and use it correctly.
They should also probably have fairly in-depth knowledge of at least one or two layers beneath their working layer. For example, many web developers know a bit about how browsers render content and about the HTTP protocol.
I'd say it is as long as you accept one thing.
Knowing how to find answers to coding problems is a skill just like any other.
In my opinion, the days of having to remember everything you need to know are long gone, there is far too much tech we have to use on a daily basis to be able to remember it all. Not to mention that it is constantly changing and keeping up is almost impossible while trying to get a days work done.
I think that knowing how to find solutions is acceptable, and I would more than happy to think that my developers do just that as needed, and I'd also like to think they share the results with the rest of the team...the good news...they do just that :)
Depends on how often the knowledge is needed. If it comes up often in your workflow I say do yourself a favor and learn the concept well. For one offs, Google away!