211–220 of 270 posts
Speaking as a rockstar bacon ninja Viking pirate robot code fu guru unicorn damn hell aged and wise app developer, many of these problems could be mitigated or eliminated in the web dev world if the web dev community could just slow down a little and clean up their existing messes before inventing twice as many new slightly shinier messes every funding cycle or so.
Having taught many non-programmers to start their programming journey, this article rings very true. The "cliff of confusion" he describes is a function of the Dunning-Kruger effect ( http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect ), which indicates that you don't know how bad you are at something until you get better at it. As an educator, the challenge is to make that cliff as unscary as possible and ch…
The Dunning-Kruger effect pretty much sums up myself. I feel like I have a firm grasp on the structure and syntax of JS, but now I'm questioning whether I really do. I always feel awful, as I can't really implement anything, and am always frustrated when I can't get off the ground starting a project. I just don't know how to actually _do things_ with code. So, in essence, I think I know the language, and in a sense I…
Build something, anything. Then set it aside for a while, come back to it and improve it. Reading code you wrote a couple of months ago will highlight very quickly the parts that are clear and concise and those that are not.
Pick an open source project that is interesting to you and improve the documentation. Writing clear documentation requires a depth of knowledge that surpasses just employing it.
Give a presentation on and/or tutor someone on a topic. Like writing docs, this requires being able to think clearly about the topic.
Perhaps the curve of familiarity with the other for any empiricist.
Look at a totally foreign thing. First comes cautiousness about whether it exists, but then just by looking you get a vague notion that it's a coherent thing. Then curiosity draws you closer to it and therefore you see the thing in greater detail. Some of the newly visible bits mess with your idealised picture of the thing from before. Only if you decide to persevere in understanding this other do you start to integrate these discordant stimuli into the currently running model of it. As the thing comes into clearer focus you realise that the discoveries are slowly revealing negative entropy. It's safe there. Following the trail inevitably results in reaching the end of it.
If only there were a standardised protocol for consuming the universe.
The ability to program (and can we please stop calling it 'coding' as a career path? Writing code is the smallest part of programming) is something that either comes naturally to you or it doesn't.
If it does, you wonder why everyone says it's hard - to you, it's almost literally how you think. The pieces just fall into place.
If it doesn't, it's always an uphill battle. You can acquire proficiency through a lot of hard, painful work. Most people who fit this category can do the job, but they do it through rote following of procedure as opposed to exploration and intuition that comes from putting the pieces together without consciously thinking about it.
This isn't a matter of intelligence. it's just a certain way of thinking that some seem to have and some don't. Plenty of extremely smart people aren't built for programming.
On the other hand, if we accepted this, then there wouldn't be much of a business model left for the likes of vikingcodeschool.com ;)
In my day (taking the liberty of revisionist exaggeration), one could write cool and useful programs with a simple language and text based i/o. Programming and software development were nearly the same thing, and were exactly the same if you were an amateur like me.
Today, languages are necessarily more complex in order to interface with ... enormous systems and libraries of exponentially increasing complexity. At least, that's what it seems like from where I sit. And software development goes way beyond programming. Once you learn to program, there's a whole 'nother stage of learning how to use big code libraries, frameworks, IDE's, and so forth. I'm not sure anybody has figured out how to teach someone else to approach a big code library.
Maybe there should be a set of lessons in Code Academy, whose point is to learn how to get stuff done using the documentation and related lore (StackOverflow, etc.) for a complex library like MatPlotLib. I did something similar when I agreed to teach a review session for a math course that I had never taken. I had no choice but to show how to approach a textbook as a resource for solving problems. Maybe my students got more out of that, than they would have from just memorizing formulas.
For kids, a way around this problem might be to strip away the complexity by teaching programming on a platform that just doesn't have all of that stuff, e.g., Arduino.
Many of the coders I know (which is mostly folk in their 40s) never learned from scratch. More often, we started in support roles, and slowly worked into the code. First, learning to read it to help troubleshoot issue, then making basic changes, and slowly picking up more and more of a specific codebase. Once the basics were understood, we'd start making basic apps on our own, often while still supporting more comple…
This. I so agree with this. I was lucky enough to fiddle with computers as a kid, so I kind of knew what I wanted to do, so I had years and years of "play time" in which I gently and accidentally introduced myself into programming, databases, operating systems, hardware, the web, etc. Often, things that I never thought would be useful turned out to be down the road. I also learned to be more fearless when experimenti…
What sticks out is the idea of learning to code with the idea of becoming 'Job Ready'. As others have said, seemingly treating the process as a means to an end rather than a journey in and of itself.
No one learns to walk in order to hike up mountains. We start out with a fuzzy basic idea that it'd be cool if we could just move across the floor a bit and get closer to somewhere. And oh, isn't it fun to watch the world fly by!
Programming has always been that way for me. Making a computer print Hello World on the screen, and then draw a circle, and maybe calculate some primes, and so on... the entire process is learning. You're always learning. In those early days I had no magazines, no Internet, no peers to compare myself to... I just sat at a screen and tinkered, cobbling together bits from various scripts and tinkering.
Mastering it - now that's a different kettle of fish entirely.
Maybe it's some sort of capitalistic artifact, the drive to push faster and harder and more efficiently. Not being able to sit back and just, be, without constant comparison or anxiety.
Earlier quoted context omitted.
If you rely on your compiler to tell you that your code is correct, there are whole classes of bugs that are waiting to surprise you in production. I think that many years of developing large applications in Perl were really good for me. Perl is compiled when you run it, so you get the basic-syntax check that you get with other languages. But it's also very lenient, so you learn through experience to get your logic r…
There is a difference from RELY on compile to catch 100% of bugs, vs having an awesome type system that can take whole CLASSES of bugs and make them impossible to get past a compile. Is a statically typed language more likely than a dynamic language to work correctly in production, if both have 0 tests? Yes. Is either ideal? No. Can both be improved by adding a few tests? Yes.
I'm not sure I agree. "Work correctly" does not just mean "compile correctly". I would want to see a lot of evidence to back up any assertion that programs written in statically typed languages are less likely to contain logic errors that compile and run just fine but don't do what the programmer (or his client) actually wanted.
I agree that neither is ideal and that adding testing can improve any code.
Earlier quoted context omitted.
I don't really agree with the notion that software development is something that others cannot learn if they try to do it; that seems like a very harsh perspective which, from my anecdotal experience, is far from the truth. Any skill can be learned if you have the discipline to put in regular effort: that's just the way the human mind works. I do agree that for a lot of people, Software Engineering is easier because…
Sure, most people can 'learn' most things - but how well can they apply them? How good a developer / musician / etc will they be? I feel that this 'anyone can code' movement is good up to a point, and dangerous beyond that. In the same way that we don't need more half-arse and incompetent engineers, lawyers, doctors, pilots, we don't need similarly incapable developers. The field of software engineering is still in i…
Here's where I disagree with other people - software development is special in that it requires focus, relentlessness, intelligence, creativity and I also find it interesting that many software developers tend to suffer conditions from the autistic spectrum. To me that's a clear sign that software development requires the mind to be hardwired in a certain way. And the thing is - I never needed handholding, which is w…
This describes me quite well. However, I'm not sure that this addiction is required in order to do software development at all.
There is evidence that with certain concepts in software development--pointers and recursion are two that come to mind--people either grok them or they don't, and if they don't, no amount of education or training seems to help. But I'm not sure the ability to grok these concepts is always correlated with the addiction.