-
[Comment removed by author]
-
-
Agreed. I find that having a physical or digital notebook handy lets me vent the “pressure” of ideas, incoming tasks, or random questions since I know they won’t be lost when they get pushed out of my working memory. Then I can move on with my task. It’s amazing how much my brain churns up though. I’ll sometimes come away from a task that took an hour with a page full of notes, tasks, and questions.
-
Exactly the same. One thing that helps is doing dailies with my team and actually write this down. It’s also great to know who is working on what to be sure to take time if anyone needs to come to check things with you. So for example, I can set some potential tasks that I’ll do if I do not need to collaborate. It’s also great to share oneself work because you feel accountable for some productivity and actually helps to face the impostor syndrome.
-
-
I used to have a water bottle near me to keep myself hydrated, but if i have it near me, i don’t take breaks (away from my keyboard) and sit in my place for long time. Now I need to walk two to three rows to drink water and i also have my frequent breaks away from my keyboard. During this walk I’m able to relax and come up with ideas if I’m stuck on something for long.
-
-
A little bit of me feels that Gary’s video’s skip over the hard part of programming, which is thinking about how you’re going to design your code in the first place. There’s a subtext in the way Gary’s videos are presented that code should just flow straight out of your fingers in a linear progression from idea to implementation - that “real” programmers just sit down & churn out code. I don’t think this subtext is deliberate, but it’s there nonetheless.
If you want to learn the “mechanics” of programming in ruby (or whatever) then video’s like Gary’s can be handy, but sometimes you just have to sit and think. “Real” programmers don’t necessarily get given a problem and immediately sit down and churn out a solution.
(A counter to this point is that sitting down and getting on with it is a good discipline to have! I just don’t want people to get the idea that being able to access this flow state is some automatic thing that defines whether you’re a ‘good programmer’ or not.)
-
-
-
-
I know people who do screencasts prepare a lot and would edit the video. But seeing him write code in a flow without thinking makes me feel intimidated. I’m a programmer with 3 years experience, and i do feel there is a huge gap between him and me. I don’t even want to think how a entry level programmer would feel.
-
I’m a programmer with 3 years experience, and i do feel there is a huge gap between him and me. I don’t even want to think how a entry level programmer would feel.
I like woodworking. I’m not very good, as I do it only in my spare time. I watch videos of true masters of the craft and they’re amazing, far faster than me, seemingly one with the grain, never a chipped-out dovetail or errant cut line. It’s inspirational – look how good I could be with decades of practice and dedication!
I don’t get it. What is it about our craft that you’d ever wish that experience, practice, and years of dedication to mastery didn’t matter? Surely it would be horribly depressing and demoralizing if you saw someone who had sunk decades into your craft was no more skilled and sure than you, with a mere 3 years? Surely you would quit, recognizing this all as a waste of your time, if a dedicated craftsman displayed no more skill than an entry-level apprentice?
What a shallow and small skill this would be if you’d maxed out your ability to improve in a mere 3 years.
-
He’s clearly written this code a bunch of times before, and has thought through some of the basic issues, and is working from a set of notes - perhaps not exact line by line notes, but certainly he knows how he’s going to do this before he starts the video; nothing to be intimidated by.
-
3 years isn’t that much (and I say this as someone out of college for a year). In may other industries, you’re a scrub until you’re five years in - more for some jobs. I’d say don’t stress and do your best to push yourself.
Oh, and Gary is open about spending countless hours redoing and editing videos so they look perfect. He’s not doing this in one shot.
-
Exactly. Also IIRC, he never seems to make mistakes, or rewrite code in the videos I’ve seen - there’s no “oops, that was a dead end, actually I need to do it this way”. Which makes sense to a certain extent in an educational context - you don’t want to show people bad habits! - but at the same time it gives a completely unrealistic view of how real programmers write code.
I don’t actually know, but suspect that he does a significant amount of prep for these videos. It’s the elision of that prep that makes the result misleading.
-
-
-
-
Something wrong with the site? It says connection insecure for me (Invalid certificate).
-
No, site works fine. It’s just that our browsers are defective.
-
-
Inspired by reading OpenBSD Daily blog post, I’ve installed OpenBSD in virtualbox. This is my first try with *BSD. So far so good. I have started by reading the basic commands implementations.
-
Make sure that if you use a remote terminal to talk to it, you set the font to Comic Sans.
-
Writing test cases. During initial stage of my junior developer job, i learned a lot by testing the software product my company develops. I wrote test cases which includes on how a particular feature works, how it should work etc. The requirement for this is that i need to find out whether already a document exits? whether it is up to date? or i should update the document. And i have to interact with the testing team to know how to test and other teams which my module interacts. By testing i learned whether it was working the way it is intended? how it works? etc.
Read code. When something doesn’t work, i was always told to read the code. Since the code base is old, it doesn’t have much document on how things work and even if it has, they will be different from what the code does. So whenever something doesn’t work, my first step would be reading the code. I also developed a habit of reading code daily, so that whenever the code compiles (it would take 20mins), i would choose some module and start reading the code. By reading code, i have found more bugs in the code that would require difficult steps for the issue to happen.
Document what you do. Because many times i need to solve the same/similar problem. I don’t want to waste time solving it multiple times. Documenting what issue you faced, the root cause, the fix and how much time you spent on the issue will be very useful.