|
You remind me that I learned the existance of "set next statement" after 3.5 years of developing. All in VS. With complex problems ranging from hardware management to layered integration of Sobel transforms with heuristic detection of patterns.
And that the first 3 months I didn't know how to use the debugger effectively and debugget with prints. Image processing. With prints.
As I say, I know nothing about computers. Beacuse each time I think of what I knew two years ago I end up saying "I didn't know anything back then". Since it happened regularly in the past 20 years I can predict that two years from now I'll be looking back and saying that now I know nothing about computers, so I accept it as of now.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
I would add only one thing to all the good advises... Choose pet project, that seems to be hard... That will force you to learn new things every day...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
In my experience the type of "technical learning" necessary for programming skills in a given OS and "stack" varies from person to person; of course it varies by general cognitive abilities in dealing with logic and abstractions, symbol and semantics, but, there is, also, imho, a kind of "innate" cognitive style which is quite "individual."
Some folks, in my experience, are endowed with strength at learning from "the top down" ... from abstraction at a high-level to "nitty-gritty," from algorithm to code: give them a set of Backus-Naur diagrams and they can visualize how those abstractions "work" in a "real world" computer language as a dynamic set of parsing/object-construction, etc., "rules."
Other folks, like me, in contrast, are "bottom up" learners who learn best by making multiple passes over the high-level concepts and forma structure in the context of focusing on some specific technique, or problem to solve, most often while experimenting/prototyping. I believe this type of learner tends to need a lot of "hands-on" before they can form an accurate "mental model" of how the high-level abstractions and concepts "work" in the code.
I do believe that intense periods of all-out effort, total immersion, in learning are very valuable; at the same time, I believe it is an important skill to develop to know when (as in your example where the screen starts dancing) that you are over-loaded mentally, and the ratio of effort to learning turns negative.
A phenomenon I have noticed in myself, and others, is a kind of "carry-forward" from the first language/stack one learns in depth to your future learning new languages/stacks. For me, the first really deep-dive was with Lisp, and then, PostScript, and I find myself thinking, sometimes, that I wish .NET had the kind of "dictionary stack" to govern current semantic state, and other save/restore-state mechanisms, like the 'gsave/grestore graphic-state semantics, that PostScript has 
If you accept the premise of a tendency for learning in "bottom up" vs. "top down" style, and a connection with the general cognitive style of a person, then, from an educational point of view ... what follows ?
I'd say the strong "bottom upper" at times need to engage in intensive immersion in the higher-level abstractions, in the structure, semantics, algorithms, design-patterns. And, I'd say the strong "top downer" needs to "get their hands dirty," and work with lower-level idiosyncratic features, like dealing with the quirks of the UI Controls that .NET provides in WinForms, WPF, ASP.Net, etc.; like manipulation of bit-maps, using API calls to "fill in the gaps" where the front-end of the stack doesn't provide the functionality you need.
I see nothing wrong with reaching mastery of how to find what you need in the documentation as you need it ... without an accurate "mental model" and understanding of the micro-aspects of that topic's state/behavior paradigm. In my experience with teaching programming, the person who behaves/feels (most often compulsively) like they "understand nothing" unless they "understand everything" is in deep trouble, and needs being "brought to earth" ... gently
Perhaps there is an opposite to that hypothetical "syndrome" where a person may feel over-confident because they can make code that "works," without realizing that they have not accumulated the type of higher-level knowledge that allows them to generalize from their current achievements to other problem areas ?
When I hear someone say, like you did, that you really enjoy getting "deep" into programming: well, I think that is absolutely great !
Oh, I didn't mean to go on like this ...
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Excellent post!
I'm top-down AND bottom-up. I do best when I start with a high level view of the subject and dig into the theory. This gives me a visualization of what I'm dealing with, including rough parameters.
Then I get my hands dirty, digging into the details and building little pieces, and grouping them into bigger pieces. I have to have the hands-on work to truly learn anything (maybe everyone does to some extent).
The initial picture is always full of holes. There are too many details left out by verbal descriptions. The hands-on work fills in those gaps and corrects misperceptions.
When learning a new language I build an address book application. I've had the same data model since 1991 and know the requirements inside-n-out. This lets me focus on building an application, from data access layer to GUI.
|
|
|
|
|
Quote: P.S. Is there any standardized way to improve at debugging? I'm still trying to learn my way around the VS debugger.
not really, has has been said before - practice .. that being said, when I started out in 'c' etc, command-line stuff on a Unix platform, all we had was 'printf', none of this fancy IDE stuff .. so, I'd suggest, for my 0.02 worth
a) learn how to step through a program looking at variables etc, setting breakpoints
b) learn a logging framework - log4net or similar - avoid printf("At step 1, value of x is ....") throughout your code
c) look at techniques of 'incremental' building of programs/solving problems - test the basic algorithms/classes etc with unit tests etc that way you can be sure your 'base'/foundation is firm before you proceed
d) wether you use command-line or Atlassian SourceTree or GitKraken, as you develop bigger programs, use source control - sure, when you start out, you backup important files/directories as date/time stamped zip files, yes ? but 'rolling back' from these if you mess something up is a pain - so learn and like a Source Control System
above all - read voraciously, have a thirst for knowledge - its not necessarily about the language/framework, its about being able to break problems/issues down into solvable chunks and then modelling them
|
|
|
|
|
Experience, experience, experience.
It's over 4 years I program full time and before that I did all kind of microprojects - I still bang my head on some "simple" problems.
The best way to avoid long fruitless hours is to invest time in designing what you want to achieve and the structure of what you're building. That streamlines and divides the problems into smaller ones that can be tackled more easily. Also keep in mind that you may have to redesing one thing several times and recognize it after long coding hours - how to improve at that? Wasting time. Doing things less than optimal.
With time you'll know what worked and what not and you'll be able to work faster. It takes a year to make a year of experience, there are no shortcuts.
Just don't ever think you have nothing to improve or learn, keep your mind open and be ready to acknowledge when you did suboptimal things. It happens.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
I agree, good design can make a massive difference. Invest time in learning design patterns, that will save hours of debug/code time later.
|
|
|
|
|
I'll add a couple of other things I have found invaluable over the years.
Another set of eyes. Because you are so close to the code you can end up seeing what you expect to see, having someone else look at a problem has often identified an error that I just can't see no matter hown long I look at it.
Another developer you can talk the problem over with. Often as you try and explain the problem to your colleague you can solve the issue without the other person needing to say a word. This can really weird some people out but it does work.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: Another developer you can talk the problem over with. Often as you try and explain the problem to your colleague you can solve the issue without the other person needing to say a word. This can really weird some people out but it does work.
Tested and true. Absolutely invaluable. 
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
Agreed. My cat is an excellent problem solver in this way. 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I would not trust a cat needs you to solve a problem 
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
You'd be surprised: they are pretty good, because they have a way of staring right at you with an expression of "So? Do I care?" all the damn time that makes you doubt what you are saying is important or relevant. And that leads you to doubt what you believe is right...which helps you go  and realize where you went wrong!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I've used Griff's "ask the cat" strategy many times with great success.
A typical "cat programming" session might go something like "Okay, Mog, check this - for some reason this binding doesn't work even though x, y and z are all in place and I know that event gets fired and the dependency is there and that's always going to work unless ... unless ... of course! God! I'm an idiot, why didn't I think of that? Mog, your a genius! Have a kitty treat!"
It's not, needless to say, that the cat provides the answer but that you find yourself restating the problem in a slightly different way - it also helps that you're not physically looking at the code. When you look too hard at code, it's easy to go in circles.
I often find that I'll wake up in the morning with a solution to something that seemed utterly impenetrable the day before. Overnight, you subconsciously reframe the problem and then the solution becomes obvious in a way that just doesn't happen if you chain yourself to your desk.
|
|
|
|
|
I can give you the tip, to handle every return value, if it is an error. Often a logging message is enough.
Try yourself in throwing and handling your own exceptions.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
My number one tip when it comes to the situation where you spend a few hours figuring something out which in the end was fairly simple is to get the habit in to work in seeing it from another angle.
Hard to explain without having it sound cliche but this is one of those situations where often enough you just need to air the problem with someone else. Try to explain it out loud to yourself as if you were describing it to someone or if possible find someone to discuss it with.
It can actually be fairly useful to speak with someone that's not a programmer/coder because then you have to dissect the problem in order for them to understand what's going on and that will help you solve it.
Another thing I might suggest is to take on something a little bigger to challenge yourself and grow. Something where you just can't jump straight in to and requires more design and thought.
A few years ago I made a simple tamaguchi game in c++ for my wife where she easily just could make new pngs to add more clothing, faces etc.
At the time it seemed so trivial to me, I knew what I wanted to do and started doing it. But after a little while it grew so complex that it was a total mess and I realise that I had spent more time writing a UI library than working on a game and once I striped the game away I had something that was easy to reuse. Helped reinforce oop principles in me after realising my mistakes as well as how to better plan ahead.
I like programming games because they can range from super simple to complex behemoths. You can work closely with the gpu, on network or AI and UI. It's also easy to get ideas, just pick something and see if you can replicate it and improve to your liking.
|
|
|
|
|
If I understand what you're saying correctly, the issue is the "impedance mismatch" between knowing what you want to do and knowing how to do it. It can be very impeding!
For example, when doing Python programming, I know various basic things about the language and its syntax, but I don't know hardly anything about useful 3rd party utilities (or even the ones built into Python!) and I certainly don't know the Pythonic way of doing things. So, for example, in C#, if I want to iterate over an IEnumerable, I have a couple options that are well known to me:
for (var foo in bunchAFoos) {...}
or
bunchAFoos.ForEach((f)=>...);
But how do I even write a loop in Python? Is:
for foo in bunchAFoos:
The best way? What if I want an index? Well, I use an extension method in C#:
bunchAFoos.ForEachWithIndex((idx, foo) => ...);
I have google the answer for Python:
for index, foo in enumerate(self.buncAFoos):
And is that the best way?
It gets worse -- do I wrap my Python functions in a class (their called "methods" then)? How do create a static singleton of the class? How do I derive from a class? How do I call the base method? Discovering that I have to explicitly call the base class constructor was a WTF is going wrong debugging session.
And then there's the debugger (using Visual Studio Python plugin). Why can't I step over the code>if statement? On a fluke, I changed:
if self.state == AppState.performing:
to:
if (self.state == AppState.performing):
and weirdly, I can now step over the if statement in the debugger. Why?
How do enums work in Python? (Answer: use the "enum" module and write it like non-member assignments, like this:
class AppState(Enum):
offline = 1
online = 2
unconfigured = 3
waiting = 4
performing = 5
TheOnlyRealTodd wrote: Is this pretty typical for a new coder or coders in general?
It's typical of coders with a new language/framework/platform. Don't even get me started on the lunacy of trying to launch an app at startup in Debian (or any *nix OS.)
So, to re-iterate, the impedance mismatch between knowing something because I've read a book or watched a few videos, vs. knowing how to do a thing, well, that can be cough shocking.
Marc
|
|
|
|
|
Marc Clifton wrote: the impedance mismatch between knowing something because I've read a book or watched a few videos, vs. knowing how to do a thing
I call that "eloquent," and I speak from direct experience of a life-time of swimming upstream all-too-slowly against the flux of mis-matched impediments, kept afloat only by some talents in rationalization and denail
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
modified 5-Jul-16 1:47am.
|
|
|
|
|
you hit denail on dehead with that one.
|
|
|
|
|
I've once spent 9 hours (starting at 21:12) trying to solve a problem and after I went to bed and got up, I found the easy solution that I simply missed because I was running head first into a wall instead of simply turning back and bypass the wall.
|
|
|
|
|
|
|
You are not alone bro! I also had the same problem and I am still have.It is about a month now since I have stated learning Mobile application development using Android Studio.Actually at the beginning I was total confused and I was about to "Give up" and Quit doing those stuffs but I remember my parents insists to me that Giving up is a sin,So I reflected those words and I see my self was about to commit sin so I continue learning.
I encourage you to struggle hard and you will succed.Also apart from that I recommend you to read this book "The Dip" written by Seth G. it will help you.
Remember that "Programmers of Today are the wizards of the Future"
|
|
|
|
|
A lot of really good advice here, and it reflects a lot of the techniques that I use to learn and get things done: Take on projects that stretch your capabilities, try to explain the issue to someone else, talking it over with another coder, etc.
One that I haven't seen mentioned is this: Really really put in the time to learn some deep basic knowledge, such as data structures, algorithms, and computation theory. I spent about 8 years doing coding work, both on the side and for pay, and I was pretty good at getting things done. I learned like you did, and felt pretty adept at taking on new challenges and expanding my repertoire.
Then the business I was in went under, and I used my GI bill to go back to school (rather than call myself unemployed) for a graduate degree in Comp Sci. Out of all the classes, it was the Algorithms, Data Structures, and Computational Theory classes that taught me the most--and it all came together in the class where we wrote a basic operating system from scratch.
(I had never had these classes before--I was an Aerospace Engineer from way back, and took up software development because, like you, I enjoyed it and had a lot more patience for coding than anything else)
When I went back to work (needed the money more than the degree), I found that my problem-solving skills (and even better, my "problem-recognition" skills) had improved tremendously. And because I had a better understanding of how computers work, the particular language I was working in became less important than figuring out what the software needed to do as a whole.
You don't have to actually take classes, but it's like automobile maintenance: If you don't understand the basics of electrical circuits and 4-stroke engines, you can still get the job done, but it'll take a lot longer and there's a lot of "magic" involved. Learning the underlying principles of hash tables, stacks, sorting algorithms, and memory management makes a world of difference.
...and BTW, even with all this, I still run into problems that take me 2-3 days to figure out, even if the final answer is simple. But it's the ability to find this "simple" solution that we get paid for, right?
vuolsi così colà dove si puote
ciò che si vuole, e più non dimandare
--The answer to Minos and any question of "Why are we doing it this way?"
|
|
|
|
|
You believe you are proficient, but I'm afraid all you really know is how to spell the keywords. With many years of practice, you will suffer less frequently from these periods of inability to move forward. Bad news, huh?
It's called "coder's block": writer's block for code. You get over coders block by...wait for it...coding. Partly this means experience coding, but it also means not allowing yourself to be blocked. You must write something.
- If you can't write a function, try writing just the function signature
- If you can't write the signature, try writing an introductory comment
- Try writing a unit test that uses the function, to see how you will use the thing you want to write
- Get out a blank sheet of notepaper and try writing a few phrases or keywords about what you want the function to do
Just as soon as you have written something, you will begin to review it mentally. You'll begin to see if you like it. You'll engage whole new subsystems of your brain to work on the problem.
A separate problem is that you have to have some familiarity with each library you use. It takes a long time to look at all the documentation for a library to see if it has a function you need. Not so long to remember what order the arguments are in. But this is just temporary.
|
|
|
|
|
John Robbins has some good advice on debugging with .NET. Pick up one of his books or see what is otherwise available. I haven't checked this particular presentation, but channel 9 has this presentation.[^]
My professor (who became a Touring award winner...) had a very specific principle for proving code: Define INVARIANTS in your code. That means you have known expectations of variables (and state) at specific points. Test for those. .NET provides Debug.Assert which allows you to test for those invariants and doesn't require you to remove them for production (just use build configuration).
Add to that by considering test first (test driven development), or at least keep testing in mind when you code.
Many other great insights posted here - I can vouch for pretty much all of them after almost 40 years in the business.
When it comes to extended sessions - that boils down to how much you can mentally keep track of and how TIRED you are. Some times, nothing beats being "in the zone" for an extended period, but only when you are actually making noticeable progress or following multiple leads. But when you start to spin your wheels, you are probably better off taking a break.
I like to do Sudoku puzzles, and the ones I have trouble with at night before bed are usually quickly solved the next morning. Same thing with programming challenges.
* Learn and practice using patterns.
* Describe problems out loud or in writing. That forces you to think them through.
* Learn by teaching others. That challenges you to know.
* Don't rely on what you know - things change. I have had to unlearn more things that I have had to learn. Look it up.
* Get comfortable with a good search engine (I like DuckDuckGo.com). Realize that not all answers on line are good answers.
* Have fun coding, and don't forget to have a life away from a keyboard and screen.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
