As someone who still needs to trudge through the API and tutorials to do what I need to do, every piece of code that works perfectly is a victory. And every time I feel lighter and less bogged down. It’s a big part of what drives me; to feel that “level up” feeling. So I’ve got to ask, what does it feel like after that?
I’d like to think that I would work at a whim and do whatever strikes me, knowing that it would come easy and success would be my only obstacle. And I want to believe that this will be me one day: the kind of dev that just does it. That the code will spill from my finger tips, that the ground will glid beneath my feet, that it’s in my muscle memory and second nature.
The thing that you describe… not quite. But something pretty close is definitely achievable.
Trying to jumping straight from “problem” to “code” is a part of what slows people down. From a problem, come up with a variety of potential solutions (these are code agnostic). Evaluate those, and turn one into some form of software design (this probably isn’t code agnostic, though in many cases it certainly could be). Turn that design into code.
Since each of those steps have a closer relationship to one another than the problem does to the code itself you can get to the point where you follow that process almost innately. You can also work through the process for a bunch of problems (or “requirements”, to use more formal software terminology) at once, find solutions that work well together, and combine them into larger designs that end up solving more than one problem.
The important part of being able to do that is learning to solve new problems for yourself.
Also, the API guide and other similar references are things you’ll never leave behind. Nor should you - you’ve limited learning time when developing software, and spending it rote-learning stuff you could look up at a whim as you need it isn’t an optimal way to spend it.
LOL. Yes and no. Here is the lifecycle of a programmer from my experience.
Beginner: You start small with for loops and if statements. Gradually you build a mental toolbox of how to solve simple problems. You are constantly having to look up how to do simple tasks. You wonder if you’re ever going to get the hang of this. You have a few small successes, and you can look back with pride at what you’ve learned. But you feel miles away from achieving your dreams.
Intermediate: Through pure tenacity you’ve bulled your way through problems you had no idea how to solve. Your small toolbox has grown to include multiple design patterns and several API’s. You are constantly seeing familiar problems and you know the solution automatically. You still have to look up solutions because you’re always doing something new–pushing your envelope. It seems you can tackle any challenge! No task it too complex! Your dreams are just within your grasp!
Experienced: After countless attempts at impossibly large projects, you realize there is such a thing as too complex. While you have confidence you CAN solve any problem, your experience helps you choose the ones you SHOULD solve. You are finding more and more that the best way is often the simplest. You keep all projects smaller than what you believe you can finish in 3 months, and ruthlessly cull the rest. While your code can be elegant and clean, you know when to just get the job done quick and dirty. And yes, experienced programmers still look things up.
The beginner programmer can do the simple.
The intermediate programmer can do the complex.
The experienced programmer can make the complex simple.
No. Not unless your Hugh Jackman playing a hacker in a sure-to-fail blockbuster.
Programming is one part problem solving, one part design, and one (probably small) part actually writing code. You can, theoretically at least, become this code conjurer that you’re envisioning, but you will still have to contend with and spend time on the other two parts.
I’m reminded of those montage sequences in movies and TV shows that depict authors hammering away a their typewriters, where the only restriction to their creativity is the speed at which they can type. It’s an entertaining bit of fiction, but I’m sure it never happens in real life. Writing, like coding, will always be struggle.
And if I may add to that part… You have experienced it enough times now to know that what you schedule three months for will actually end up taking nine.
I agree with this, but might change it slightly: While I can code any solution I want, I know that looking up what others have done will be quicker and easier, so that still happens a lot. Actually implementing those solutions is usually a breeze, though, and doesn’t often result in even more looking stuff up.
Tutorials, however, are intensely painful. You know that feeling you get while you’re at the dentist and he’s numbed your mouth and you’re listening to the drill and just waiting for him to do the work? And then you’re just sitting there staring at the ceiling while he does the work, and afterwards you know what happened but think it just should have been a lot quicker? That’s what it feels like to listen to most tutorials. There’s a ton of waiting for things to start, then a ton of waiting for things to continue, and when it’s all over you’re like, “What? That was all that got done? Cripes.”
They don’t make tutorials for experts. They make them for beginners. And that makes them super painful.
I am pretty good at assessing a project, both my own and those I am hired for, and finding a simple way through the complexity. My one area that still boggles me here and there is rotations. I can set up code to Lerp or Slerp and etc from this rotation to that, convert back and forth from quaternions to eulers, when localRotation versus rotation should be used. I still get pinwheeling here and there where I am telling the code to rotate 10 degrees between two rotations and it rotates 350 degrees. Or I set a specific rotation in code I set up in editor and copied the numbers and checking it during play I get the most oddball rotations where none of the numbers is what I input. I am guilty of drawing the Submariner and Spiderman during trig classes as there were no personal computers back then and I didn’t “need” triangles because I wasn’t going to be a sailor…LOL. This is the one area I need to get a grip on how the guts of it work for that one in ten where it just doesn’t do what I had in mind and transcribed to code.
Sort of. In my experience, instead of spending half an hour figuring out how to do basic things like instantiating 10 prefabs lined up in a row, I can just do it (as you say). When I mess something up and get an error, I can usually just say “oh, duh” and fix it immediately instead of having to search for what it means. The messing up decreases somewhat, but doesn’t go away, and I’m highly suspicious of code that works right the first time (the dev meme about that exists for a reason I guess…). I still refer to the docs fairly frequently, but I don’t have to do that for every line of code anymore.
However, being able to “just do” the basic stuff means you then focus on the less-basic stuff, so you’re back to spending time struggling to figure out how to do that. So it’s a never-ending process. If you ever find yourself being able to effortlessly write all code you can think of, then you’re probably an immortal AI or something.
I find it strangely comforting to know that I’ll always need to look things up.
And yes, tutorials are AGONY!!!
“Dude! Increase your computer’s font size! No one can read that! And you can edit out all the sighs and " Uh"s. And why are you talking about that non-related thing? Just get on with it!!! And… Crap, what was that? What did he just do?!”
At this point, I’m finding that I’m mostly using the docs to do something quickly. Normal use cases these days are trying to figure out which one of the fifteen variants of raycast I want.
But then again I had forty tabs open the last time I was doing something in the editor, so I suppose it’s mostly dependent on what I have gotten comfortable with.
Haha, yeah, but that sounds like a bad tutorial. Once you reach a certain level of experience even a good tutorial isn’t an efficient way to get information. That’s why I’m always hesitant when things only have tutorials as docs - if someone doesn’t know how to make good documentation and/or doesn’t see the value in it, what does that imply about what’s going on under the hood…?
The struggle definitely changes, though. Early on the code is the hard part, so that’s where the struggle is. Once you’ve mastered the coding part then it becomes the problems and solutions that are the challenge. Converting a solution (via a design) to code becomes easy, the challenge becomes in coming up with solutions to increasingly complex problems. (And as others have said, a perfectly valid approach to that is often to find some alternative where the problems are less complex.)
I’ve never understood the appeal of video tutorials when it comes to programming. At least with something like 3D modelling it makes sense because it’s a very visual task, but with programming it doesn’t seem to offer any advantage over text tutorials, and it has all the downsides (like not being able to speed-read, not being able to read back and forth / back-reference easily, etc).
One thing I remember one of my students experiencing was the shift from feature-code to script-code: we spent months working on building up the ‘systems’ of his game - inventory, on-screen messaging, interactive objects, etc - but, having done all that, he was suddenly able to write the code for the gameplay objectives ('when the player touches object X, add ‘x’ to their inventory, delete the object, and display a ‘you got the object’ message) incredibly quickly. All that up-front work to build solid and flexible systems seriously paid off when it came to building the layer on top of them.
I learn’t way more watching video tutorials because they help me see the final results… I can’t read a book and understand a thing, by watching, I can firmly grasp what everything does without ever even hardly looking at the code.
I’m very hands on, if i can not physically hold something it’s very hard for me to learn anything,
so just even seeing the final outcome helped me understand better what things did.
The Unity Documentation has hardly helped me with anything whatsoever, I’ve never understood some of it, it doesn’t make sense sometimes, i’ve had a few cases it just didn’t plainly work lol.
Even with copy paste.
But the second I look up on Youtube what I’m trying to do, boom it works lol.
Yup, everyone has different ways of learning that work for them. I actually miss huge printed manuals for software. Those were the days. 400 pages of awesomeness. Hell yeah.
Here is the lifecycle of a programmer from my experience.
