It was not an auspicious start to my career in computer science.
I'd argue the opposite!
Learning how to "run" code in your head, cover edge cases and invariants, is a great skill to practice. When I was at a hospital after a difficult operation, I used to write down pages and pages of C64 programs in my notebook, too :-)
Even if I never even typed all them out later, I like to think this made me a better programmer. It trains your brain in a way that REPL doesn't.
When it came time to try my code, I spent a while correcting some basic misconceptions that I had developed but that hadn't been corrected by an actual compiler.
Worked out really well for me - I'm employed well as a programmer, and I got to come to Shakespeare basically fresh when I was old enough to actually appreciate the work.
Write -> Compile -> Fix Compile Errors -> Compile -> Fix Compile Errors -> Compile -> Fix Compile Errors -> Compile -> Run -> Fix Runtime Bugs -> Compile -> Run -> Fix Runtime Bugs -> Compile -> Run -> Fix Runtime Bugs -> Compile -> Run -> Fix Runtime Bugs -> Compile -> Run -> Fix Runtime Bugs -> Git Push and Pray
With maybe a few "Write Unit Tests" steps intermixed. Totally different mentality. Is it really a faster or more productive way to work?
I’ll also rely heavily on my IDE’s function signature completion, to remind me whether some method I’m calling takes an int or an unsigned int, rather than have it memorized like I used to.
This might be why a lot of people (including me) hate whiteboard-coding interviews: we’ve gotten so spoiled by our tools that we can’t code without them!
That's not a 'crutch' - it's literally what those compiler errors are for! The alternative would be for the compiler to do something non-sensical, which would error out at runtime.
And when it comes to white-board coding, you should arguably be using pseudo-code anyway - your goal is then not to come up with something that will run, but to convince your interviewer that the code is 'morally' correct and that any subsequent fixes are well within your skill level.
Computers have been a godsend for my penmenship. On the other hand, I guess I relied on them too much as a kid.
(To see this, do a 45 degree '/' with your right-hand pen, then leave the tip in the middle and make your left hand into a mirror image in the plane of the '/')
Sure, I do the same. I wouldn't call it a 'crutch' though; it's just using the tools you have available to you.
Isn't that like someone saying they've gotten so spoiled by training wheels, they can't ride a bike without them? It's not like I'm one to talk 100% of the time. I think I couldn't get my company's project to build, without a few weeks of reading and understanding a lot more of the build system. However, I've also coded on an 8 bit machine by flipping 8 switches and pressing a commit button for each byte.
It's a worthwhile exercise to do some coding with nothing but a text editor and a debugger once in a while. That isn't going 100% to the bare metal, but it's a level that's very worthwhile for working on basic skills. Entire programming education books have been based on this idea.
Whether being able to work without the chain is also important is an independent issue. (I happen to prefer vim+scripting languages over IDEs+compiled. But I recognize it as a personal preference, and not a question of moral superiority.)
Right, but pro cyclists don't say they couldn't do it without piece of equipment X. X is just a performance boost. Some coders say they couldn't practically do it at all without X. There would be a big difference in fitness between a commuter being unable to make a certain trip without a motor assist, and a rider who could do the same trip without the motor assist. I think most would look askance at a "pro" in the 1st category.
If you're working with a toolchain and aren't leaning on it, you're not working to your full potential.
Yes, but you need to be wary that you're using the toolchain for its intended purpose. The toolchain is supposed to be saving you typing and lookup time. It's not supposed to be substituting for your actual understanding of the code. The former is a good thing, and you should be good at using the tool for that. The latter is a bad thing, and you shouldn't be doing that. By working out with nothing but an editor sometimes, you can work out in a way that guards against that.
No football player plays actual games running through tires, but the exercise is apparently helpful.
But I recognize it as a personal preference, and not a question of moral superiority.
It's not moral superiority. It's using tools as intended and not substituting for understanding.
The problem is, I don't think anyone completely understands the code when they write it. 90% of the time, you're writing code with a library written by someone else and you have an abstract understanding of what it does. That's the whole point of code is to abstract as much detail as possible. Its so you don't have to know what the machine code equivalent of X CPU add instruction is when coding a website for example. You just type + and the compiler/interpreter does everything for you.
The trick is this: Do you actually have that good abstract working understanding, or have you only convinced yourself? This is the difference between sloppily convincing yourself you understand a word salad, or being able to coherently teach a concept. It's even a further step to be able to understand the specification of something in enough detail to be able to implement it and to see potential pitfalls. (This is the difference between real science and cargo cult science: Predictive Power.)
You just type + and the compiler/interpreter does everything for you.
There's a world of difference between just typing "+" or "/" because you've seen it and just going on token frequency/pattern matching, and really understanding the concept.
X = Y + Z
X = Y / Z
If one is a careful programmer who has done substantive work, one should know there's a world of difference between a specification of a program that sounds good on the surface and a really good specification. After many years, one will have encountered many specifications which had to be re-thought one or more times to be practically implemented.
No, you shouldn't have to always rewire your program in hardware from NAND gates you make yourself from silicon in the bucket of sand under your desk. (I've actually quit a job because the manager was going overboard with that attitude.) But you should be able to peek under the next level of abstraction, and have enough working knowledge to become wary and know when you should be peeking. Either you can do this, or you do not have that level of skill/knowledge. Simple as that.
(Addendum: If you think to yourself that you can't do that, there's two common reactions to that. Either you tell yourself excuses and denigrate and don't bother, or you roll up your sleeves and learn it for yourself. You choose.)
X = Y + ZObviously, but that is more of a concept in understanding mathematics than writing and understanding code. For example, do you need to know that Y / 0 returns a custom exception inherited from several parent classes under the parent Exception? Are you really thinking about all that when you code? Or is it mostly irrelevant and you just need to know that an error occurs and you need to be mindful of it (regardless of whether the error comes in the form of an exception, error code, hardware interrupt, etc.)
API's are written specifically to avoid needing to peek under the code and you should only really need to if they are poorly documented. Even then, you only seem to think only the next level of abstraction is warranted and not other levels (i.e. IL/x86 assembly or machine code). This next level of abstraction can yield important learning in code optimization because what you write in a higher level language can be implemented in multiple ways at a lower one (sometimes at a performance determent).
Either way, most coding is a black box exercise. While looking under the hood is useful and informative at times, nobody has the brain capacity nor time to absorb it all and apply it. Which is why the smart people built upon other smart people to put a model in place that can be applied without knowing what machine instructions your computer spits out after compilation, or without knowing the implementation details of how you get a list of a specific type or how it adds/removes/copies/etc. Same as science. You don't need to do an experiment every time to know the motion of the planets, measuring their positions in the sky each time to calculate the orbits and deriving the equations through calculus. You simply skip to the step of Newtonian mechanics and kinematic equations.
Imagine if everyone had to learn how an engine worked in order to operate a vehicle. Hardly anyone would be able to drive.
Indeed. In a conversation like this, the mention of divide by zero is just supposed to evoke all of that for an audience of programmers.
API's are written specifically to avoid needing to peek under the code
Any product is designed to be simply used. The difference between an end user and a pro is that the pro can sometimes go a little further and sometimes needs to because they can push the product harder.
Either way, most coding is a black box exercise.
As is most professional activity of any kind. Most of any job is kind of routine. That's why they call it "routine." What distinguishes the consummate pro is the ability to go beyond when needed.
While looking under the hood is useful and informative at times, nobody has the brain capacity nor time to absorb it all and apply it. Which is why the smart people built upon other smart people
Being a smart person means taking into account context and getting the best cost/benefit. Nobody who is "smart" would advocate knowing absolutely everything about everything, all the time. That's clearly a straw man. (Perhaps you are pressing things in a certain direction?) It's also clearly not the position I'm advocating for. Likewise, nobody who's smart would simply advocate for ignorance. Not even the smartest people are infallible. Smart people are simply prepared for when things go wrong.
Imagine if everyone had to learn how an engine worked in order to operate a vehicle. Hardly anyone would be able to drive.
Funny you should mention this, but I was about to bring up that analogy, then decided to leave it off. I guess you're indicating it should be brought up. A typical driver doesn't need to know much about their engine. However, a professional driver of one of several different types is very well served by some knowledge of engines. Such knowledge isn't needed all the time, but when it is needed, the potential costs of not knowing can be quite high. You could lose a race, lose money, or lose a life.
Professional drivers really don't need to know much outside of the behavior of what they experience while driving. This is why there are things like pit crews and staff that support the driver. Its so the driver has to think about driving, not what fuel to air mixture is adequate to prevent piston knock.
This is the problem, nobody adequately defines what a professional is and can only be seen when "someone knows what to do" which implies having broad, wide scoping knowledge about a topic which again, is supposed to be something that isn't required and is the point of having models in the first place.
Its not that having in depth knowledge is bad, its just that having in depth knowledge is often not required and it doesn't make you any less of a professional for not "knowing it at the right time".
And with regards to Y / 0, a programmer is mostly thinking about how to catch the exception properly for a given task. He does not care that the exception is nested X levels deep in the class hierarchy. He does not even need to know the mathematical understanding of Y / 0, just that its an error state. He does not care how the error code is generated, just that it exists. He does not care how the list adds/removes items and what the worst case runtime is, he just cares about its use. Because the point is, you're not supposed to care about implementation details. Abstraction is king and you can go a long way without knowing a lot.
I think it's pretty clear from this thread. In the context of programming, it's someone who can do what a "mere user" can do, but who can push the thing to extreme limits, modify it to do something completely new, or fix it if it's somehow broken or has holes in its design.
Professional drivers really don't need to know much outside of the behavior of what they experience while driving.
In the case of racecar drivers: They need an intuitive understanding of what their engine is capable of, and how far they can push it based on what it's been doing. They need an understanding of driving physics. They need a good feeling of driving physics, and they need to understand how the wear they've put into their tires could affect performance. There's a lot to know about competition rules and regulations. They need to know enough about the physics of car aerodynamics, and how it affects their grip in different situations. Not knowing such things has literally gotten professional drivers killed. And professional encompasses more than just racecar drivers. Truck drivers working in extreme conditions have to know quite a bit, it turns out. Truck drivers who are pointedly ignorant about their engines can end up costing someone a lot of money in repairs. "Professional driver" actually encompasses a number of careers. The point is, professionals have to know a lot that goes much, much deeper than just being an "end user."
And with regards to Y / 0, a programmer is mostly thinking about how to catch the exception properly for a given task.
Not necessarily. This would vary a lot depending on the language and the particular task.
He does not care how the list adds/removes items and what the worst case runtime is, he just cares about its use.
Not necessarily. This would vary a lot depending on the language and the particular task.
Because the point is, you're not supposed to care about implementation details. Abstraction is king and you can go a long way without knowing a lot.
The king is just another fallible mortal. All abstractions leak. I'll grant that there are professionals what can mostly get away with basically just being an end user. 95+% of the time, everything will be routine, and copacetic. It's that last few percent where things can get really dicey and expensive. (Also the basis of a lot of the money for "consultants.") If someone wants to run a shop where someone isn't prepared with the know-how to deal with that, I guess it's their business. That's not what I'd consider a very a high level of "professional."
Its not clear at all because you can simply move the goal post. Someone with 20 years of programming in client side apps struggles with programming a website and can't figure things out on X situation without help. Does that mean they are automatically not professional?
In the case of racecar drivers: They need an intuitive understanding of what their engine is capable of, and how far they can push it based on what it's been doing. They need an understanding of driving physics. They need a good feeling of driving physics, and they need to understand how the wear they've put into their tires could affect performance...
Again, another arbitrary definition. I bet you can go to most professional drivers and they won't understand the physics at all, they have an understanding from experience and consultation of the experts, but I would bet that 90% of drivers aren't going to pull out calculus or kinematic equations to analyze a race track. They either hire someone to do that or use a computer (most likely) to simulate the race. And even then, the simulations are inaccurate due to driver emotional state. My guess is they have, at most, a surface level understanding of driving physics.
Not necessarily. This would vary a lot depending on the language and the particular task.
So does everything, but we know that Y/0 is a programmed failure state based on the library being used. So the solution is either, catch the exception (and by catch, I mean control in a broader sense since you can condition the input), use a different library, or write your own library. I would hope, in a business setting and in most settings, you would choose to catch the exception or control for it in some way.
It's that last few percent where things can get really dicey and expensive. (Also the basis of a lot of the money for "consultants.") If someone wants to run a shop where someone isn't prepared with the know-how to deal with that, I guess it's their business. That's not what I'd consider a very a high level of "professional."
So you base your decision on the few percent of people that can do X vs. the 95% of people that can't, but can solve all other problems without knowing the details? Seems like a very irrational outlook considering the following: a) Some of these top 5% of people may not even exist b) If they do exist, they are most likely consulting c) They are being paid more than most businesses can afford d) They work for companies you probably don't work at e) They are doing research work and publishing papers you probably never read f) They probably can't solve X problem outside their expertise without assistance
But the point is that even if abstractions leak, they rarely do. And that's the whole point of engineering and technological advancement in general, is so that you don't need to know the details.
People are experts in different things, but general skills can be applied. My wife notes that there's an effectiveness and mindfulness constant to be applied to "years of experience." There are people in her field who have 20 years of experience, who know less about the regulations and subtle aspects than she has learned in 2.
I bet you can go to most professional drivers and they won't understand the physics at all
Note that I wrote intuitive understanding. It would be highly inaccurate to say they "don't understand it at all." I would question the general understanding of someone who would say that.
My guess is they have, at most, a surface level understanding of driving physics.
Something that someone has practiced over many years in a competitive environment isn't just "surface." This is why educated people should have at least two areas in which they've delved deeply, so they have a firsthand knowledge of what "deeply" means for knowledge.
I would bet that 90% of drivers aren't going to pull out calculus or kinematic equations to analyze a race track.
That's a ridiculous suggestion. Projecting that position on someone is either grasping at straws to make a straw man, or some other form of bias. If a driver knows enough to intuit there might be a way he can improve his line, such that he can seek out another expert's help, then I'd say he could well be a "consummate pro." It's the curiosity, awareness, and drive to peek under the surface which is the difference.
So you base your decision on the few percent of people that can do X vs. the 95% of people that can't, but can solve all other problems without knowing the details?
A more concise way of putting it, is, "Are you smart and informed enough to know what you don't know? Is that sufficient to keep you out of trouble?" The Pareto often rears its ugly head in reality. That last few percent can really, really cost you.
If they do exist, they are most likely consulting
I was an example.
They are being paid more than most businesses can afford
There's an old saying for this: "A fool and his money are soon parted."
They work for companies you probably don't work at
Again, I was once such a consultant. Also, there are coworkers at my current job who are curious, energetic, and smart enough to have such a position, but who don't want one right at the moment.
They are doing research work and publishing papers you probably never read
Nah. Just a modest level of basic curiosity is enough to get you there.
They probably can't solve X problem outside their expertise without assistance
Which is fine, if they're smart enough to know what they don't know, so that they can gracefully navigate their situation.
But the point is that even if abstractions leak, they rarely do.
Boats leak. Could be rarely. Could be a lot. Both can be true of the same boat. It depends on how hard you're pushing that equipment. People can and do make money driving a boat no harder than a dilettante hobbyist. People can and do make money using technology at about that level too. In either case, I just hope everyone knows what they don't know, so no one gets in over their head and drowns.
And that's the whole point of engineering and technological advancement in general, is so that you don't need to know the details.
The point is to get stuff done and to save money while making money. Knowledge is power, but ignorance helps someone else's margins. "You pays your money, and you makes your choice."
A lot of what compilers catch are careless errors like mistyped variable names and missing semi-colons. This is not fundamental understanding of the code. This is a level of care that it is perfectly fine to let your toolchain handle for you.
A more interesting case is type checking. One of the reasons to use static type checking is that you are free to change the type of a variable or argument to a function, and then let your compiler tell you what needs to be fixed. Each individual fix is straightforward and easy - you understand it. But thanks to the toolchain you don't have to find them.
Choosing to work with dynamic typing and exercise vigilance is a reasonable choice. (In fact this is what I choose.) Choosing to work with static typing and let the toolchain help you in ways that it was designed to help is a reasonable choice. But choosing to work with static typing and refusing to take advantage of how it lets a toolchain help you is not a choice that makes sense to me.
That you should know how to operate without the tools is one thing - I strongly support it. But maintaining your practice in doing so is quite another.
The biggest chunk of my professional work is still in Smalltalk.
But choosing to work with static typing and refusing to take advantage of how it lets a toolchain help you is not a choice that makes sense to me.
Yet despite being a Smalltalker for years, I'm still an advocate of static type annotation. It enables you to do more refactoring than not having it. It enables you to know sooner about incorrectly written code.
That you should know how to operate without the tools is one thing - I strongly support it. But maintaining your practice in doing so is quite another.
The "maintaining your practice" I'm advocating in this thread is merely: "Code without an IDE once in awhile to make sure you know how to operate without the tools." You don't have to fire drill every day. There is some benefit to doing it once in awhile, however.
I'm not advocating not using an IDE. I'm merely advocating for knowing exactly what it is the IDE is doing for you and doing to you. It's just wise practice for any professional power tool.
It's like manual memory allocation and proper deallocation - been there, done that, but after 10+ years of working with GC languages, I would definitely have some memory leak bugs if I suddenly had to do that again. It is a basic skill, but just as many other basic skills, it's one that you can ignore in most domains.
Bad analogy. It's more like a "lumberjack" who thinks all it takes is pressing the controls on a chainsaw. There's some more, very important things to know, and not knowing them can cost time and money or even get someone badly hurt. The chainsaw has to be maintained, with possibly severe consequences if it isn't. You need to know how to get the tree to fall where it's supposed to. You have to know how to cut so the weight of the tree doesn't clamp the chain.
It's a bad analogy, because the important issue is whether someone is letting the tool substitute for understanding. I guess some rube might think their chainsaw is so powerful, they don't have to worry about how they cut down the tree. It's more like sailors who think they can just lean on GPS instead of having skills. Those are the guys who collide their ships and get people killed. It's more like pilots who weren't great student pilots, and they make critical mistakes and program the autopilot into the side of a mountain or do the wrong thing when the plane is stalling or always depend on the auto-landing system and don't really know how to do a manual landing and wreck the plane. (Those are all things that really happened.)
Just because some big fraction of time being a "professional" is just being an end user doesn't mean there isn't something more beyond that which is very important. I guess it just has to do with what level of "professional" you aspire to be.
It's like manual memory allocation and proper deallocation - been there, done that, but after 10+ years of working with GC languages, I would definitely have some memory leak bugs if I suddenly had to do that again. It is a basic skill, but just as many other basic skills, it's one that you can ignore in most domains.
If you're doing something hard enough, you still have to think about stuff like that in a GC environment. I know, because I worked for a Smalltalk vendor. You can even have memory leaks in a GC environment. There's a lot of stuff you can ignore -- most of the time -- but can come and bite you real hard if you're not prepared for it.
He skipped the "ctrl+enter" part of the workflow.
In the past you had to be Hawkeye to program, now most of us just put on our Ironman suit and get on with it.
It's like situational awareness: https://en.wikipedia.org/wiki/Situation_awareness
Yes, if you're writing your -own- code, learning to envision what the system must do in your head first is very, very valuable.
When you're on a team, however, you -have- to compartmentalize. You have to create abstractions, black boxes, functionalities that you -could- dive into, but which you will accept only understanding at a contract (interface) level. The skill of envisioning the system is still useful, of course, but there will be black boxes.
The problem that causes, of course, is that every abstraction is leaky. You didn't know that calling this method also fired off this event, and so you -also- triggered that event. Or whatever. Hence, bugs and iteration. You also have to deal with -bad- interfaces, a bajillion parameters, or a parameter object that isn't intuitively obvious how to initialize, and you start having to iterate.
This is an amazing metaphor, thank you for sharing!
Computer time is no longer at a premium and bugs can be fixed.
Useful, creative, and clear solutions usually trump perfectly correct ones, except in special cases such as when life is on the line or you're writing programs to fly to the moon where getting it right the first time is of utmost importance.
Actually I've found that the most useful solutions are those that are creative and clear.
But yeah, it totally depends what one is doing. Usually if the algorithm is mission critical and the component is mission critical you can weasel out enough time to make it right (so you don't have to return it to ever again and you get a reputation as a guy who's code just works).
These individuals are uncommon.
One coworker of mine was the son of one of the engineers of the XC-142 tiltwing aircraft. He started a project to make a functional scale model, and this was before Arduino, so we decided to use a Gumstix Linux board. (Because of its generous number of GPIO outputs.) I wrote a bit-banging implementation of the flight surface control mixing in C. It "just worked." No errors. It just ran the 1st time. It was even flown on a simpler aircraft.
This isn't my usual way, however. Usually, I'm quite iterative. If you're going to write a program that works the 1st time, then it helps if the control flow is relatively simple, there isn't a lot of complexity that can come about with interaction with state, and it does just one thing.
I learnt programming writing small games, so quick iteration is my first instinct, and I can see myself sometimes jumping to write code too quickly.
I wouldn't trust someone to deliver quality software who produces multiple syntax and multiple runtime errors while coding, especially when modern IDE's fix typos on the fly? What about all the runtime errors he didn't test for?
Is that flow really that common?
Sure, I cause errors all the time, but my workflow includes a compile time error maybe once in 2 trys and an obviously fixable runtime error once in maybe 10 times. Sure there are these countless of edgecase errors I don't even know about, but that's not the thing catchable with this workflow and I wonder if someone with that workflow, who misses the obvious, does miss even more edgecases.
Also don't a lot of tech companies require (mostly) correct whiteboard coding exactly because of this for quite some time?