Blank source files are scary yo.
There are a near infinite number of choices that can be made when confronted with a blank file. And the ramifications of those initial choices will live on, possibly for decades! (I spent 10 years at Microsoft where it wasn't uncommon to come across 20+ year old code still in use.)
More than once I've initialized a new project, started at my blank folder structure, and spent a few minutes thinking "here we go again".
Boy do I miss those days now that I work for larger companies and with larger teams where the opportunity to do that is pretty rare. Give me a blank slate all day for any project.
It’s pervasive in lots of aspects of my life beyond programming, where I get anxious having to make decisions. I will drag my feet to have to make a final decision, even if it’s a restaurant choice. I’d much rather have the obvious right choice in my face than have to pick between multiple good choices.
I face this same anxiety when staring at a blank source file too.
(Yes, I’m working on finding a therapist, but even picking one gives me the same anxiety)
This means you become partly responsible for the quality of the product you pay for. If the burrito is bad, you are to blame because you chose the ingredients. I think that makes me anxious when in Chipotle's.
In programming it does slow your progress if you have to frequently spend time deciding which choice is the best. Not only anxiety but also plain lost time.
Barry Schwartz, is that you?
I so much hate those project generators. First thing I do when I generate some create react app is going through it and delete stuff. Everything. To start from absolute minimum.
I can accept some project generators being an option. But I never understood people who make it default way to go.
Your post was kind of eye opener for me.
I hate deciding where the ubiquitous "utils" folder should go in any given project!
They are. But the more programs you write, the better you get at it.
It also helps to devise a personal architecture or two for different projects. I have some that I lean on, and that means I can bootstrap myself fairly quickly. It took a while to get there though.
True
> I do think Google has caused some of this.
I think it a lot of it is the frameworks and people constantly trying to shortcut the method of building something with code. We have so many frameworks, tools, plugins and other stuff that it makes it easier NOT to learn anything deeply any more. Pick a JS Framework and I'll give you a dozen plugins or tools that have already been built to write your code for you. All you, as a developer have to do is string them together.
By building all of these shortcuts, no one really needs to learn Angular, you have their site as a reference and tons of material to help you. Developers actually learn in the absence of knowledge where they have to sit down and learn it without knowing there is a crutch or fallback if they get stuck. I think today's developers just get as far as they can and then start googling for a solution because they know that someone has already built a date picker in ten different languages, thousands times already. Why go back and reinvent the wheel when you don't have to?
Because it creates lazy developers.
An entirely other issue is why learn some framework inside and out if its going to be obsolete in a few years? Remember when everybody loved Backbone and Express? You tell someone in the Dev community today you use either of those and you'll get laughed right out of the bar.
I think its just a lot of things that work against developers learning more than then they really need in any given situation.
If you're copying and pasting your core expertise from stack overflow, then, I hate to break it to you, but you'll never successfully differentiate your product.
Very rarely do you see a startup hiring to solve brand new technical problems. At the end of the day, most engineering work boils down to implementing CRUD apps with textbook architecture.
If this was true, it would bring a significant economic advantage to a startup if it would not use leetcode style questions for job interviews, but instead ask hard questions about these textbook architectures.
Find the most readable color of a font for a given background on most displays. You could do extensive research on colors for something that on the first look sounds rather trivial or find a very thoroughly worked out solution on stack exchange.
It is difficult enough to advertise self-made software when many people are looking for off-the-self solutions. So being fast and therefore affordable is quite important.
I mostly develop for embedded systems on custom hardware so ready to use solutions are rare. But if I want to visualize process data in a browser? Please give me all your thousands of dependencies Javascript.
An algorithm I implement from scratch? Very rare. This takes time and thorough testing compared to something that is already solved.
Though I'd agree that no engineers should be copying code without understanding its intent and interfaces.
Programming isn't my day job, but I do frequently write code from scratch (and refactor it, heh). I interviewed for one entry-level programming position; they did not appreciate my technique.
And interactivity can be an extremely effective way of experimenting and learning how things work and fit together so that you can rapidly develop a mental model of your core primitives and how to put them together in different ways.
It's also part of the appeal of TDD. Small iterative loops with rapid feedback.
I am a self-taught programmer. I copy, but I also innovate. I don’t follow at all the academic approach (I never studied CS or was very good in school). But I don’t paralyze when I can’t find anything to copy from like a Roomba stuck on a rug.
Do you have a term for me?
Also, academic research on computer science, as I lack much of the basics.
I am happy building websites and web apps.
But I am confident enough to know I can innovate and create complex solutions for the kinds of problems I face.
I'm guessing the reality in your case isn't quite as severe but that's sort of where some "jigglers" sit.
When I hear "I don't follow at all the academic approach" what I'm hearing is you don't even know what is actually taught in a CS degree. Might be wrong but that's what I'm hearing. A lot of it isn't really that academic but sure some of it is. I'm self-taught and I worked as a programmer before I got my CS degree (as a teenager) but my self studies included CS topics (algorithms and data structures etc.) and I never copied any code or "jiggled" anything when I got started, everything was written from zero. What I did occasionally do is implement algorithms (i.e. the algorithm is known, write the code, which I guess is a form of copying).
On the plus side you've obviously acquired some good skills doing all this and you are likely smart. If you're happy with where you are (let's call this a "Software Integrator" maybe) that's fine. If you want to become better you probably should put in the time and learn some of the things you've been avoiding either formally or on your own (unlike when I was a kid there's endless resources now).
This is accurate. I don’t. My impression is “algorithms and data structures”, which is fuzzy for me. I don’t care at all about algorithms. Data structures I think I should know more about at some point.
I considered studying CS after starting working with software development, but decided I don’t want to. Kind of related, but I also decided that I don’t want to study leetcode too, even though there is a financial incentive to do it.
I am happy being someone that some arrogant developers like to call “web developer”, “programmer” or, at most, “software developer” as opposed to what a “software engineer” is. I understand the difference that those people try to point out. And I agree there is a difference and I don’t care to be on the side of line that I am. It does bother me that every time I see someone making a point of showing where the line is, it’s from a point of arrogance, entitlement. This does bother me, and I felt that tone in the comment I replied to.
If I see an engineer constantly do this, I would think that they are insecure and are constantly attempting to prove that they are "real" programmers (whatever that means).
The way I see it, we are here to solve business problems and the chances of your problem being so unique that similar solutions don't already exist is rather low.
Let's face it, the majority of software work is pluming work and wiring APIs these days. Very few people are tasked with implementing their own sorting algorithm and even if they are, you can bet that they will scaffold from another algorithm to get started..
Yes, one should not blindly copy and paste from Stackoverflow but researching, refactoring, thinking about the task at hand and using existing tools and libraries are all part of the process.
And yes, I learn most effectively by copying too. Showing me a couple of working project and letting me implement a bunch of simple tasks by jiggling existing ones usually works for me way faster than throwing manuals and tutorials at me. Manuals have its place - when I know enough to know what to look up - and so do tutorials, but "learn by copying" is the most optimal way of getting bootstrapped for many people, including me. There's nothing wrong with that, if you don't stop at that stage but continue learning.
Trial&error mode works well when working with randoms, e.g. exploration, research, acquiring information, identifying unknowns. Literate mode works well when working with exacts. Identifications for example produce exacts from unknowns. Enough facts enables you to build stuffs out of it like Lego. This is where literate mode works well.
Jiggle programmers that does not quite grow out of their jiggling mode is because they stay in trial&error mode and does not slide slowly into the literate end of the spectrum. After acquiring some facts, they don't deduct or intuit from them. They don't attempt to philosophize a bit.
A problem as simple as "how to do X after the window loads" for example, some programmer can find `window.addEventListener("load", X);` in stack overflow, but the main differentiator lies whether after fixing the issue, they care enough to at least wonder about what's the meaning of `window`, `addEventListener`, `load`, "why is the call shaped that way", "what is Event and what is Listener". Those who do slide slowly into their literate mode.
It is also not less dangerous to be stuck in the literate mode. Although this happens rarer, often to more experienced people.
We're all jiggle programmers then. Once the applications architecture is established, we hang new feature on it by following that architecture.
Very very few of us get to only write code from scratch every day. Most of the time, when I'm writing from 0, I'm working on a R&D PoC. If I'm not doing that, I'm jiggle programming a new feature into an existing architecture.
> With the rise of self-taught programmers, you will see more take this copying approach than the academic redistillation.
I was self-taught before university. I learned on a C=64 and then an early x86 back in the day. If you didn't figure it out on your own, you hoped you would see it in a magazine or book some place. I learned a lot about how computers worked at a fundamental level from the C=64. I don't think self-taught is the issue. I think it's how much the person really wants to know about computers and CS.
My current project is boring (especially since i finished the code logic like 9 months ago), but since I'm paid to upgrade/deploy the stuff I'm not that disfranchised. (I won't lie and say I'm as productive, I'm clearly not)
I don't think I'm really able to work alone or unpaid. Which is weird, because I really, really enjoyed the two dozen school projects I've done, especially those who took 2+months
In my opinion the way to get them through it is loads of pair programming and stopping them and reminding them they haven't stopped to think about the entire context when you catch them doing it (or when they come to ask for help in the ideal case).
I'm not sure if I ever went through this phase, but not everyone has the luxury of developing their programming skills at a leisurely pace from highschool all the way through college.
Strong junior programmers usually fail by rewriting everything from scratch, having no concept of DRY, libraries, or how to effectively break logic into methods. But inability to generate their own code is not a common failure mode!
It's only weak junior programmers (that is, people who simply are not going to become strong developers) who approach a problem and, in the absence of the ability to write code from scratch, try to find something to copy-paste.
This has been my experience too. It's also common (maybe even nearly universal) for devs to go thru a stage where "rewiting" feels like the path of least resistance. This is usually (not always) wrong, but until you've ramped up in several very different codebases it's difficult to see how something so foreign can end up being as productive as what you're used to.
It's messier than simply that too. Even though I may be the inferior coder to them, I am not necessarily without any capacity to reason and improve on something.
So what happens is I pick something up that someone else wrote, and I see things I think should be done differently, and much of that is probably perfectly true and correct, as far as it goes.
But also, even while some of my ideas were correct and better than what's in there, at the same time it's also true (ends up turning out to have been true, but I only recognize it later) that much of what I didn't like and ripped out and re-wrote, was actually just me not actually grasping the thoery of operation of the original code.
My new replacement may still work and may even look more organized or more easy to follow, but turns out not to handle some edge cases the original code not only handled, but did so in some elegant trick way that isn't obvious from reading it, but ends up handling more conditions in fewer lines, fewer cpu ops, fewer memory ops, fewer db/net calls, etc.
I live with myself by deciding it's good enough that I at least recognize this process and am generally improving day by day. That has to be all anyone can really expect.
I'd also wouldn't frown on just calling them developer. They just need a senior developer to tell them not to rewrite everything.
Anyway, regardless of whether they're really strong or not, the couple I've mentored have become tremendously valuable to my company, with performance outstripping my own (I think because of the higher tolerance to shitty repetitive frontend work).
Sure, technically you are a Junior again if you use a new technology, but assuming the MO of the language is not completely unlike one you're familiar with (for example OOP vs functional vs whatever).
I mean, at least that's what I need to do - but maybe "how was this syntax again?" paired with "I don't like these docs" might only superficially be copy/pasting from SO, because you know what you're writing, but you don't have the words of the language...
My impression is that a trend started in the 90s which has taken over the industry where programmers that are capable of building things from scratch and keeping everything in their heads are much less valuable compared to those who are "weaker" but much more capable of communicating and cooperating.
They usually cannot write code from scratch, or when they do it contains a huge amount of plumbing copied from other familiar codebases without any reason for its purpose. It's kind of like they can read a foreign language, but they cannot speak it. Or maybe a parrot who can produce the sounds without the meaning.
I do think Google has caused some of this. But the other secret, I think it's how most people program by default. Animals largely learn by copying. The deconstruction of concepts to primitives, and synthesis of these primitives into new ideas if a very academic way to approach things. Centuries have proven this approach is superior, but it takes a huge amount of effort, and many things are lost in this process. (Ever do a physics problem with spherical cows?) With the rise of self-taught programmers, you will see more take this copying approach than the academic redistillation.