In this company, there are two kinds of developers
-
When i was in tech support i learned from a guy who was about to retire. I used to ask him how they did the job before google, but he'd always shut me down with an angry "Hey!" like he didn't want to talk about it.
My 10c worth: We expected to, and were expected to, know not only what to do, but why to do it exactly that way. Or stated differently: We knew the inner workings of the mechanisms we used. Always make sure that you are familiar with the layer immediately below the one you are working on! (You can't go all the way down to the transistors, but go at least one level down!) Of course that required resources and efforts (and use of books with thorough explanations), but it paid back: We made much more "good" and "correct" use of the mechanisms offered. Younger colleagues are usually very good at telling me that "the second parameter should be 4". So what does that 4 mean? Why not 3 or 5? No idea, but that's what is used in this code snippet I found when googling, and it works with 4, not with 3 or 5! ... I am never satisfied with that kind of "coding by trial and error", but I see a lot of it around me. If it works, don't ask how it works! When my younger, "helping" colleague has left, I start searching for explanation of that second parameter - if necessary, I buy a book. This is of course not a real example. Real examples would be like how OO languages have implemented abstract classes, multiple inheritance etc. How interrupts work. Locking mechanisms. Switch statements... When you know the inner workings, by heart, to a much larger degree you need not google up that code snippet to tell you "for some reason it works with 4". You would know why 4 is the right value. About 25 years ago, I participated in an EU project focusing on "Just In Time learning": If information can be fetched when you need it, you need not spend time learning it. We can save lots of resources spent on educating people that way. People may be deaf and dumb if we can give them what they need when they need it, more or less as list of detailed instructions. ... Obviously, the EU project didn't say that they wanted people to be deaf and dumb, but that is what I saw in their philosophy. (So why was I in that project??) That project never made a great success, but Google more or less provides information in the way that the EU project was talking about. Pick up some information about Bloom's model of learning (usually referred to as "the Bloom Taxonomy"), structured in levels from plain repetition up to critical assessment. Information you fetch through google doesn't go very high on the Bloom ladder: You see information reproduced and rephrased, but even the level of comprehending it is poorly supporte
-
HAve to agree - most online tutorials seems to be written by people who can't teach (or even communicate in some cases), and who don;t appear to know the subject in any detail. Many seem to have "working code" but no real idea why it works or how they got it. Video tutorials on YouTube are the worst. And sausages are the wurst.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
I don't Google because I don't know or understand the subject. I Google because I can't remember the exact darn syntax. Let me tell ya, despite many names, everything we use old or new is the same thing over and over again. We use to call them formatted text data file now they slapped a name called XML or JSON. We use to have server and now called cloud. But the syntax and steps to do it different, the concept is the same.
-
The move is completed and we have learned.... In this company, there are two kinds of developers. Those that came to work here after we still needed to collect technical books (AG After Google) Those that worked here when we still needed to collect technical books. (BG Before Google) ..They are the ones with the 55 gallon disposal bins next to their cubes.
I'll use WPF as an example of why 4" thick programming books can still be useful. I bought and read one when first learning WPF to get an understanding of all of the features. However, while coding it's quicker to find a snippet online than it is to look it up in the huge tome. If I hadn't read the book, I wouldn't know what to Google!
-
While I do recognize that there are terrible tutorials out there, there are also some terrible books out there. Also tutorials are not the only form of information available. I learned JS/TS almost exclusively through MDN[^] and TypeScriptLang[^]. Don't get me wrong - books are great. But with how rapidly technology is changing, I'd rather read up-to-date online documentation than a probably out-of-date book that isn't due a new version til next year or later. As an aside, being able to filter through web searches, compare sources, and form actual knowledge from the aggregate is an underappreciated skill. Some topics force you to use this method either due to fragmented information or such rapidly changing technology that books as a medium are insufficient. The example that pops into my head immediately is IRC. There are books but if you base an IRC client implementation on that information you'll be missing tons of modern features such as ISUPPORT, SASL, and capability negotiation while including obsolete features such as RPL_BOUNCE and RPL_SUMMONING. TL;DR: Books are great for topics that don't change often. Online documentation is better for rapidly changing, fragmented, or niche topics. Both have their fair share of terrible advice.
I totally agree. I read book when I want to understand a new subject. When come to coding, books are useless in my opinion. Most books only skim to basic and only one view. I want to know multiple ways of accomplish the same job and pick the best for a situation. I would say 90% of the time, I found answer on StackOverflow.com MSDN is great on documentation, but not so with how to get specific job done.
-
For me personally, the breakpoint was less Google and more Stackoverflow. So it'll be ASO and BSO.
-
I don't Google because I don't know or understand the subject. I Google because I can't remember the exact darn syntax. Let me tell ya, despite many names, everything we use old or new is the same thing over and over again. We use to call them formatted text data file now they slapped a name called XML or JSON. We use to have server and now called cloud. But the syntax and steps to do it different, the concept is the same.
Leng Vang wrote:
I Google because I can't remember the exact darn syntax.
So do I.
Leng Vang wrote:
We use to call them formatted text data file now they slapped a name called XML or JSON
I know what you mean, but ... XML and JSON are different in that they are "standardized" ways of transferring extremely formatted data that would previously have its own proprietary format for each application that used it. Both XML and JSON simplify the process and increase the chances that another app will be able to use the data at the same time.
Leng Vang wrote:
We use to have server and now called cloud.
I'd disagree - Cloud is a return to the very old "centralised processing" model with dumb terminals - but with a complete absence of data control and / or security within the company that we used to have. You can't even be sure if your Cloud supplier will still exist next week, much less that they backup properly, or don't employ your competitors...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
When i was in tech support i learned from a guy who was about to retire. I used to ask him how they did the job before google, but he'd always shut me down with an angry "Hey!" like he didn't want to talk about it.
-
I'll use WPF as an example of why 4" thick programming books can still be useful. I bought and read one when first learning WPF to get an understanding of all of the features. However, while coding it's quicker to find a snippet online than it is to look it up in the huge tome. If I hadn't read the book, I wouldn't know what to Google!
LOL!!! :-D
-
My 10c worth: We expected to, and were expected to, know not only what to do, but why to do it exactly that way. Or stated differently: We knew the inner workings of the mechanisms we used. Always make sure that you are familiar with the layer immediately below the one you are working on! (You can't go all the way down to the transistors, but go at least one level down!) Of course that required resources and efforts (and use of books with thorough explanations), but it paid back: We made much more "good" and "correct" use of the mechanisms offered. Younger colleagues are usually very good at telling me that "the second parameter should be 4". So what does that 4 mean? Why not 3 or 5? No idea, but that's what is used in this code snippet I found when googling, and it works with 4, not with 3 or 5! ... I am never satisfied with that kind of "coding by trial and error", but I see a lot of it around me. If it works, don't ask how it works! When my younger, "helping" colleague has left, I start searching for explanation of that second parameter - if necessary, I buy a book. This is of course not a real example. Real examples would be like how OO languages have implemented abstract classes, multiple inheritance etc. How interrupts work. Locking mechanisms. Switch statements... When you know the inner workings, by heart, to a much larger degree you need not google up that code snippet to tell you "for some reason it works with 4". You would know why 4 is the right value. About 25 years ago, I participated in an EU project focusing on "Just In Time learning": If information can be fetched when you need it, you need not spend time learning it. We can save lots of resources spent on educating people that way. People may be deaf and dumb if we can give them what they need when they need it, more or less as list of detailed instructions. ... Obviously, the EU project didn't say that they wanted people to be deaf and dumb, but that is what I saw in their philosophy. (So why was I in that project??) That project never made a great success, but Google more or less provides information in the way that the EU project was talking about. Pick up some information about Bloom's model of learning (usually referred to as "the Bloom Taxonomy"), structured in levels from plain repetition up to critical assessment. Information you fetch through google doesn't go very high on the Bloom ladder: You see information reproduced and rephrased, but even the level of comprehending it is poorly supporte
Nice... And they think they understand it. Yeah, I'm writing my fourth book about a complicated subject and wonder if anyone will read any of them. Genetics For A New Human Ecology
-
The move is completed and we have learned.... In this company, there are two kinds of developers. Those that came to work here after we still needed to collect technical books (AG After Google) Those that worked here when we still needed to collect technical books. (BG Before Google) ..They are the ones with the 55 gallon disposal bins next to their cubes.
-
Funny, I always start with Google search, but almost 99% end up in StackOverFlow. May be I should just go there directly. Perhaps because Chrome let user search by typing query directly at the URL bar.
Yeah, the good old address bar search. I started using that time saver long before Chrome existed.
