Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
How do you work with someone when they haven't been able to see that there is a range of other languages out there beyond "The One True Path"?
I mean someone who hasn't realised that the modern software professional has a range of tools in his toolbox. The person whose knee jerk reaction is, for example, "We must do this is C++!" "Everything must be done in C++!"
What's the best approach to open people up to the fact that "not everything is a nail"? How may I introduce them to having a well-equipped toolbox, selecting the best tool for the job at hand?
As long as there are valid reasons for it to be done in C++, I don't see anything wrong with this monolithic approach.
Of course a good programmer must have many different tools in his/hers toolbox, but these tools don't need to be a new language, it can simply be about learning new programming paradigms.
As much as I've experienced actually, learning many different languages doesn't make you much of a better programmer at all.
This is also true with finding the right language for the job. Yeah ok, if you're doing concurrency you might want a functional language rather than an Object Oriented language, but what are the gains of using another programming language?
At the end of the day; "Maintenance".
If it can be maintained without undue problems then the debate may well be moot and comes down to preference or at least company policy/adopted technology.
If that is satisfied then the debate becomes "Can it be built efficiently to be cost effective and not cause integration problems?"
Beyond that it's simply the screwdriver/build a house argument.
Give them a task which can be done much easily in some other language/technology and also its hard to do it the language/technology that he/she is suggesting for everything.
This way they will eventually search for alternatives as it gets harder and harder for them to accomplish the task using the language/technology that they know.
Lead by example, give them projects that play to their strengths, and encourage them to learn.
If they are given a task that is obviously better suited for some other technology and they choose to use a less effective language, don't accept the work. Tell them it's not an appropriate solution to the problem. Think of it as no different then them choosing Cobol to take the replace of a shell script -- maybe it works, but it will be hard to maintain over time, take too long to develop, require expensive tools, etc.
You also need to take a hard look at the work they do and decide if it's really a big deal or not if it's done in C++. For example, if you have plenty of staff that knows that language and they finished the task in a decent amount of time, what's the harm? On the other hand, if the language they choose slows them down or will lead to long term maintenance problems they need to be aware of that.
There are plenty of good programmers who only know one language well. That fact in and of itself can't be used to determine if they are a valuable member of a team. I've known one-language guys who were out of this word, and some that I wouldn't have on a team if they worked for free.
Don't hire them.
Put them in charge of a team of COBOL programmers.
Ask them to produce a binary that outputs an infinite Fibonacci sequence.
Then show them the few lines (or 1 line, depending on the implementation) it takes in Haskell, and that it too can be compiled into a binary so there are better ways forward.
How may I introduce them to having a
well-equipped toolbox, selecting the
best tool for the job at hand?
I believe that the opposite of "one true language" is "polyglot programming", and I will then refer to another answer of mine:
Is polyglot programming important?
I actually doubt that anybody can nowadays realize a project in one and only one language (even though there might be exceptions). The easiest way to show them the usefulness of specific tools and languages, is then to show them that they are already using several ones, e.g. SQL, build file, various XML dialect, etc.
Though I embrace the polyglot perspective, I do also believe that in many area "less is more". There is a balance to find between the number of language/tools, the learning curve, and the overall productivity.
The challenge is to decide which small set of languages/tools fit nicely together in your domain and will push productivity and creativity to new limits.
Give them a screwdriver and tell them to build a house?
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
How to get kids into programming
Suggestions on starting a child programming.
Is there a really simple programming language that I can use to teach my 6 year old son concepts of programming, syntax and logic?
I'm probably the only one here with this opinion, but I think 6 is too young to start a child on programming. Those years are critical for development of a whole host of skills including social skills that are not computer-related (that, indeed, may be antithetical to computer use) and intellectual ones that actually will contributed to computing skills later on (I'm talking about math and problem solving skills).
I've started introducing my kids to programming at the ages of 8 and 10, but I don't expect them to take a serious interest in it until their middle school years (starting at age 11/12). In general my kids spend much, much less time in front of a computer than their classmates. They both lead their classes academically and are well socially adjusted.
Logo. Designed specifically by Seymour Papert to teach children how to program how to deal with recursion etc. etc. all without using those words to put people of. Particularly when linked to turtle graphics to give a readily available and recognisable output and feedback.
Because it was designed to cover all the fundamentals in programming it does not necessarily major in anything, but the ides is to give the children all the core fundamentals.
Try Scratch.
Take a look at Small Basic from Microsoft.
By providing a small and easy to learn
programming language in a friendly and
inviting development environment,
Small Basic makes programming a
breeze. Ideal for kids and adults
alike, Small Basic helps beginners
take the first step into the wonderful
world of programming.
I think the quote sums it up, really! :)
Yes, there is Plain English Programming Language
Check out www.pythonturtle.org
Guido van Robot is a logo like application that uses Python.
(source: sourceforge.net)
I suggest python via Snake Wrangling for Kids:
“Snake Wrangling for Kids” is a
printable electronic book, for
children 8 years and older, who would
like to learn computer programming. It
covers the very basics of programming,
and uses the Python 3 programming
language to teach the concepts.
Personally I think Tcl is perfect as a beginning language, especially for young people. It has an interactive console for instant gratification, and tk is by far one of the easiest GUI toolkits on the planet. One or two lines of code to see a window on a screen. Just a couple lines of code to create a canvas and draw rudimentary shapes, etc.
I know many people don't like Tcl, but I think that's more out of ignorance than anything else. And I mean that in a good way -- if you don't understand Tcl but know more traditional languages, it's hard to see the beauty in such a simple yet powerful language. The whole definition of the language fits in a single man page, so it's easy to grasp the fundamentals.
Finally, as a teaching tool it lets you recreate just about any language construct you wish. You can not only show them for and while loops, you can create repeat/until loops, or anything other types of looping to emulate other languages.
I started learning programming in the hey-day of Pascal, a language which many would say is designed for learning. Here's a quote from Wikipedia:
Criticism
While very popular (although more so in the 1980s and early 1990s than now), implementations of Pascal which closely followed Wirth's initial definition of the language were widely criticized for being unsuitable for use outside of teaching.
Take that for what you will =)
turbo pascal? :) gwbasic? and nextly python :)
Well, Python has very English like syntax that makes it relatively easy to pick up. Python IDLE works in a read-eval-loop mode, so you don't have to go through compiling or anything. You can type code in line-by-line and get instant feedback. It also has an interactive help mode. If he needed to know what some function does, and you weren't there to help him, he could just type help(someFunction)
There was a comment about how it can become confusing when you mix tabs and spaces in Python. In response to that comment, most editors have an option to automatically replace tabs with X spaces. In IDLE, it's as simple as Format->Toggle Tabs to make it so whenever you press the tab key, it inserts 8 spaces instead of a tab.
Labview is completely visual. It's mainly used to program robots. It's extremely logic oriented. However, there's quite a big price tag on it.
SmallTalk. It was created for educational use.
I have to agree that six years old sounds a bit young though... if they don't want to learn, don't try to force them.
I think the framework is important too. Your kid should be able to create a game without too much ado. Python + pygame springs to mind.
http://en.wikipedia.org/wiki/Logo_(programming_language)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Its always said that more you program, the better you become. Sounds good and true.
But I was wondering if there is a proven route to becoming a better programmer.
Something like:
Learn a
Learn b
Learn c > 'Now you are good to burn the engines'
Try stuff around based on your learning.
The answer might be similar to a CS course roadmap, but I want to hear from successful programmers who might want to pitch in with something notable.
Thanks
It's not true that practice makes perfect.
It's perfect practice that makes perfect.
If all you do is keep repeating the same bad practices again and again, you'll only make it possible to create bad code faster.
By all means keep coding. But at the same time be critical of everything you do. Always have a jaundiced eye that looks for ways to do things better. Read widely to get new ideas. Talk to others about how they do things. Look at other people's code, good and bad.
There's no "sure" way to learn anything that I know of. If there was, anyone could master this.
All questions are rhetorical and meant to stimulate thought.
Technical parts:
Design Patterns - There are probably some specific to a domain but generally these are useful ways of starting parts of an application. Do you know MVC or MVP?
Basic algorithm starting points - Divide and conquer, dynamic programming, recursion, creating special data types like a heap, being greedy, etc.
Problem solving skills - How easily can you jump in and find where a bug is? Can you think of multiple solutions to the problem?
Abstract modelling - How well can you picture things in your head in terms of code or classes when someone is describing a problem?
High level versus low level - How well do you understand when one wants something high or low? This is just something I'd toss out there as these terms get through around a lot, like a high level view of something or a low level language.
Process parts:
Agile - Do you know Scrum, XP, and other new approaches to managing software projects? How about principles like YAGNI, DRY and KISS? Or principles like SOLID? Ideas like Broken Windows?
Developer Environment - How well do you know the IDE you use? Source Control? Continuous Integration? Do you know the bottle necks on your machine in terms of being productive?
xDD - Do you know of TDD, BDD, and other developments driven from a paradigm?
Refactoring - Do you go back over your old code and make it better or do you tend to write once and then abandon your code?
Soft skills:
Emotional Intelligence - Can be useful for presentations and working with others mostly.
Passions/Motivation - Do you know what gets your juices flowing and just kick butt in terms of being productive? Do you know what you would like to do for many many years?
My main piece of advice would be: don't be afraid to rewrite your own code. Look at stuff you wrote even a month ago and you will see flaws and want to rewrite stuff.
Make sure that you understand some fundamentals: collections, equality, hashcodes etc. These are useful across pretty much all modern languages.
Depending on the language you use - use lint and metric tools and run them over your code. Not all their suggestions will be applicable but learning which are important and which are not is important. E.g FindBugs, PMD etc for Java.
Above all refine and keep refining your work. Don't treat your work as abandonware!
Learn your 1st programming language a new programming paradigm or a
find a mentor you can learn from
Apply what you've learnt in a real world project
Learn from your mistakes and successes and goto step one
The trick is knowing what to learn first:
Programming languages - this is the place to start bcause you cannot write software without knowing at least one of these. After you've mastered one language try learning another.
Programming paradigm - i.e. object oriented, dynamic/functional programming etc. Try to learn a new one with each new language.
Design concepts - S.O.L.I.D, design patterns as well as architectural concepts.
People skills - learn to communicate your ideas.
Team leadership - learn how to sweep others and how to become a team or technological lead.
After that the sky is the limit.
I would look at improving roughly in this order, in iterations with each building on the previous one:
Programming concepts. Understand things like memory management, pointers, stacks, variable scope, etc.
Languages. Work on mastering several modern languages.
Design concepts. Learn about design patterns. Practice using them.
Communication. Often-overlooked. You can only become a highly valued Software Engineer if you can communicate effectively with non-tech people. Learn to listen and understand the needs that people are expressing, translate that into a set of requirements and a technical design, but then explain what you understood (and designed) back to them, in terms they can understand, for validation before you code. This is not an easy one to master, but it is essential.
Architectural concepts. Learn to understand the big picture of large, complex systems.
Learning a programming language is in many ways similar to learning a spoken language. The only way to get good at it is to do it as often as possible. In other works
Practice, practice, read and then practice more
Take time to learn about all sorts of coding techniques, tools and programming wisdom. This I have found to be crucial to my development. It's to easy to just code away and feel productive. What about what could be if you just had some more knowledge / weaponry under your belt to bang out that next widget.
Knowledge/know how is our real currency. The more we know the more we can make a better decision about how something should be done and do it faster.
For example, learn about:
•Development Practices, Software Design, Estimation, Methodologies Business Analysis Database Design (there are a lot of great books out there and online resources)
•Read Code - Open Source Projects are a good place for this. Read
Programming blogs
•Try to participate on Open Source
Projects.
•Look for programming user groups in
your town and/or someone who can mentor you.
And yes, as mentioned practice. Don't just read, do and watch how you will improve. :)
Practice, practice, practice.
Once you're over the basic hump of being able to program, you can also read useful books (i.e. Code Complete, Effective Java or equivalents, etc.) for ideas on how to improve your code.
First and foremost write code. Write as much as you can. Tackle hard problems. If you want to be a really good programmer you need to get into the guts of what you are doing. Spend a lot of time in debuggers looking at how things work. If you want to be a good programmer who really understands what is going on you need to get down to the metal and write highly async code, learn about how processors work and why SSE is so awesome. Understand threading primitives and be able to write them as well as describe what is actually happening in the processor. I could keep going here but you get the idea.
Second find someone who knows a lot more than you and learn. This relationship will work better if you are already deeply immersed in writing lots of code.
Third, spend some time in a large high quality open source code base. I learned a ton from the Quake I and Quake II code. Helped me be a better programmer.
Fourth take on hard problems. Push your limits. Build things that you thought were impossible. Right now I am writing a specialized compiler. I have learned so much just working on this for the last couple of months.
Sure, strictly speaking, the more you practice programming, the better you become at solving those sorts of problems. But is that what you really want?
Programming is a human activity more than a technological one, at its heart. It's easy to improve your computer skills, not so hard to improve your interpersonal skills.
Read "Journey of the Software Professional" by Hohmann. One of the concepts the concepts Hohmann describes is the "cognitive library," which includes both programming skills and non-programming skills. Expand your cognitive library, and your programming skill will improve too.
Read a lot of non-programming books too, and observe the world around you. Creating useful metaphors is an essential skill for the successful programmer. Why do restaurants do things how they do? What trade-offs is the garbage department making when they pick up the garbage every few days instead of every day? How does scaling affect how a grocery store does business? Be an inquisitive human to be a better programmer.
For me, there has to be a reason to learn something new... that is, unless I have a project in mind or some problem I need to solve, there's no hope. If that prerequisite is met, then I usually try to get "Hello, world" working, and after that the sky's the limit. So much of development these days is just learning new APIs. Occasionally there's some kind of paradigm shift that blows your mind, but that's not as common as people like to think, IMHO.
Find a program that intrigues you, one that solves a problem, or one that would simplify many of your tasks. Try to write something similar. You'll get up to speed very quickly and have fun doing it at the same time.
You can try learning one thing really well and then expanding out to programming areas that are associated with the things that you have learnt, so that you can offer complete solutions to customers.
At the same time, devote part of your time to explore things outside your comfort zone.
One you have learned something, try to learn something a little harder. Read and practice a lot about things that seem confusing at first time (lambda functins, threading, array manipulation, etc). It will take its time, but once you have practiced enough, what seemed confusing at first, will be familiar and easy.
In addition to the rest of the great advice already given here, don't be afraid to read about coding and good practice, but also take everything with a grain of salt and see what works best for you. A lot of advice is opinion.
Good sites to read:
-thedailywtf.com
-joelonsoftware.com
-codinghorror.com
-blogs.msdn.com/oldnewthing
A great place to get practice is programming competition websites. Those will help you learn how to write good algorithms, not necessarily maintainable code, but they're still a good place to start for learning.
The one I used to use (back when I had time) was:
http://uva.onlinejudge.org/
Learn more than one language. One at a time, definitely, but ultimately you should be fluent in a couple. This will give you a better perspective I think, and help you to become an expert at programming, rather than being an expert at a certain language.
Learn the ins and outs of computers at all levels, hardware, os, etc. Ideally you should be able to build your own system, install multiple operating systems on it, and diagnose just about every problem that can arise. I know many programmers who are not "computer tech people" and their failure to understand what is happening at every level becomes a major hindrance in diagnosing and fixing unusual bugs or performance issues.
As well as looking at 'last weeks code', talk to users of your work after delivery - be one yourself if possible.
Its not my bag, but some of the best coders I know have spent time supporting applications. The experience improved their product I'm sure.
eat breath dream the programming language your using (no seriously, it helps)
There are two kinds of learning -
1. Informal (like how you learned how to function in society- through interaction with peers and family)
2. Formal (like your high school training- through planned instruction)
If you want an entry-level programming job, formal training via an undergrad Computer Science/Engineering degree is the way to go. However, if you want to become a rock-star developer, it is best done by informal training- make unintentional mistakes and have senior developers curse at you, learn a design pattern because an app you are updating uses it, almost cry because a bad developer wrote a huge messy program lacking documentation and best practices and now you have to do several updates to it ASAP; thing of these nature.
It is hard for anyone to give you a list of all you need to know. It varies per area (e.g. a web developer vs. to a desktop developer) and it varies per company (e.g. Microsoft that sells software vs. General Motors that mainly just use it in their cars.) Informal traiing and being engaged in trying to learn to do your job better and get promoted is your best bet in my opinion.
To prove my point, everyone here has great answers but they all differ. Ask a rock-star developer how he learned something or when, why; they may not know- things just happen.
Practice, individually and collectively
Keep an open mind, always learn new things, don't limit yourself to what's familiar. Not solely from a tech perspective, ui design, people skills, ... Don't be afraid of what's new
Peer review, talk to people about your code, let people talk to you about their code, everyone has a unique way of looking at a problem and you will learn a great deal from peers
Love coding. If you love what you're doing, putting in alot of time seems effortless. Every coder needs the drive!
One small addition to these good answers. When I work on someone else's code, usually I pick up something new. If you have the opportunity to work with someone else that is of equal or greater skill, noticing their programming style can teach you tons.
For example, in C++ & Javascript I no longer use if() statements without braces. The reason is that it's just too easy to mistakenly put:
while (true) {
if (a > b)
print a
print b
}
This is an obvious typo, but very easy to introduce, especially if you're editing existing code. I just call it defensive programming in my mind, but little tricks like this are valuable at making you better.
So, find a peer or mentor, and work on their code.
I am not sure if the OP was looking for general advice on how to be a good programmer, but rather something more specific.
I know I am reviving this thread, but I found it because I was trying to see if anyone asked this question already.
What I had in mind was, can we come up with a "knowledge-map" of programming concepts similar to the map that Khan Academy uses.
As a programmer, I want to be able to visualize the dependencies and relationships between different ideas, so that I can understand what skill level I am currently at; what I need to know before tackling a challenging subject; and be able to visualize my progress.
The very belief in the roadmap's existence blocks the road to perfection.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Question
As stated, have you any tips to help grok / understand / get-your-head-around declarative programming languages?
Or is it simply a case that you’ve to immerse yourself in the language and it’s syntax, until it seeps in, until you get that golden moment where you Get It. This isn’t really an option as I can no longer lock myself in a room for days on end, poring over half a dozen different books on the subject matter (responsibilities being what they are and all)
So, any tips or tricks that helped you when you tackled declarative languages, any insights to pass on?
P.S. I’ll personally upvote the first answer that says “Shutup and put in the work”.
Background
I was 13 years old I when I first started wring code (basic, on my sisters Oric-1).
Since then I’ve worked with many new concepts and many different languages, taking all in my stride, me taking the upper hand quickly enough. Object Orientation? Not a bother. Event driven paradigms? Smoke me a kipper, I’ll be back for breakfast.
Owl, Mfc, ActiveX, Vb3, 4, 5 & 6, VB.Net, Pascal, Delphi, C, C++ & C#. None have stood in my way, at least not for very long.
However recently my perfect score has taken a bit of a battering.
A couple of weeks ago I threw myself into Xaml, and folks, I’m more sinking than swimming.
I think my main problem is that it’s declarative. All my other programming skills are procedural. I’ve hit this block before with MSBuild, I can copy examples of how to get MSBuild things working, but would be lost putting something together from scratch.
Back to Xaml, currently I’m going insane trying to wire triggers to properties and get the effect’s I need.
I may post my specific Xaml question here soon enough. For now I’m asking this general “declarative programming” question.
P.S. No, I'm not actually this cocky. Yes, I stumbled like hell the first time I hit OO and the first time I'd to write an event driven UI (VB3 on Windows 3.11).
Edit
It's starting to sink in, the tenacity that got me this far in this field is paying off, it just takes so much fracking time!
. . . I think I'm getting too old for this stuff . . . :)
I had to teach XSL (or XSLT, as you wish) a bunch at the beginning of the century :), and it's a different world, really. That, however, is the basis for the paradigm-shift: you have to realize that declarative languages really are different. The most important advice I have is to keep studying other people's solutions, put the work in, and really try to stop thinking in FLOW. The worst thing is that, in XSL, there is an "if" and an "else," but usually there's another way to do things.
Unlike learning OO, in XSL (or any declarative language, I suppose) you will not manage to do what you're trying to do unless you do it declaratively.
So the answer is in part, "shut up and do the work" as you suggest, but the more important point is to realize that a lot of the work is getting your head around the paradigm shift. So the real answer is, "keep your eyes peeled for the paradigm shift." You have to stop thinking in flow and start thinking in terms of rules that can fire in any order... if they're done right, it doesn't matter when they fire. When you are finally thinking in rules instead of WHEN stuff happens, you're beginning to grok the shift.
Find some examples, with explanations of the "why", from someone who really knows the language. It's learning the patterns and idioms that makes a difference.
I suspect you're trying to do imperative things in declarative land, which means you think in terms of steps. Write the dataflow down in terms of required inputs + stateless function of those inputs and see if that helps.
Try a functional or functionalesqe language like ML or Scheme.
I don't know what your specific problems with Xaml are (and I haven't used it myself) , but I've found that when using XML based technologies like XSLT, a little LISP or Scheme experience can go a long way. You might want to look at playing with the excellent scheme system available free from http://www.plt-scheme.org.
I can see where this may be blowing your mind. All those languages you list are indeed quite similar (procedural).
Once you get this down, I highly encourage you to learn a functional language as well. You may also find it tough going, but learning it will help your general coding skills greatly. You'll have a whole new bag of tricks (even in procedural languages), and you will never be afraid of recursion again.
Consider your favorite “programmer ignorance” pet peeve. The first code snippet is obviously procedural. In the second snippet you make a declarative statement that for the percentage to be valid it has to be between 0 and 100.
So i'd guess you'll have no trouble grokking declarative programming languages as long as you work on it hard enough... there is no royal road to geometry
Like Binary Worrier, I had a long history with things like C, C++, MFC, etc and have been coming up to speed on XAML, WPF, and C#. I had a side trip through HTML, Javascript, and XSLT which I think helped a great deal in preparing me for XAML.
The basic idea behind XAML is fairly straightforward - it's all about what you show, not what you do. The hard part with XAML is that there is just a ton of implementation details to learn and you wind up learning them all at the same time in order to be able to get much of anything done.
I could probably be more helpful if the question was more specific.
"Programming is about giving a computer a sequence of instructions."
Most programmers react with equanimity to this statement. It's almost like... "duh?"
But the belief in this statement is what causes people to have trouble understanding other programming paradigms. It's not true, and hasn't been for a very long time. To arrive at a better understanding of programming, many may benefit from thinking on why this statement is false.
Even if you programmed in pure assembly, modern processors would rearrange your instructions, perform branch prediction, and attempt to execute multiple potentially codependent instructions at the same time. In this way they think in terms of logical dependencies, not sequences. The sequence metaphor is the false notion that an instruction logically depends on everything that preceded it. If this were true, the best way to reason about programs would be to examine the control flow. But it is not true.
It's not just declarative programming that doesn't fit with this metaphor, but also parallel and asynchronous programming.
I find the easiest way to "grok" a language is simply to start using it exclusively for all your coding. With a completely new language I would say for me the learning curve is approximately 2 weeks of coding about 4-5 hours a day. After that point it suddenly "clicks" and you can start relying less on manuals and docs.
I took a class in college (Programming Languages). It pretty much felt like I was repeatedly slamming my head against a brick wall, but about 3/4 of the way through the class, I realized the wall wasn't there anymore; I had been beating my head against nothing for a few weeks. It was a pretty surreal feeling.
I think any other way won't have the same charm. Read Godel, Escher, Bach; listen to a lot of Emerson, Lake, and Palmer and Kaikhosru Sorabji; smoke some ganja, and put in the time.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've been programming for several years now and since then I have learned several concepts and techniques that have made me a better programmer (i.e. OOP, MVC, regex, hashing, etc). I feel too that by been able to learn several languages (basic, pascal, C/C++, lisp, prolog, python) I have widen my horizons in a very possitive way. But since some time ago I feel like I'm not learning any new good "trick". Can you suggest some interesting concept/technique/trick that could make me retake the learning flow?
A good paradigm shift always allows you to see things differently and become a better developer. I would suggest you read up on functional programming and maybe learn a functional language like Haskell or Scheme.
YAGNI (You Ain't Gonna Need It) and DTSTTCPW (Do The Simplest Thing That Could Possibly Work)
It's easy to spend a lot of time thinking about edge cases, and find that you've implemented something that's completely useless. I believe that a far better approach is to knock out a simple prototype, and then poke and prod it until you understand the domain well enough to create production code.
Recognize, however, that your prototype is going to evolve into production code whether you like it or not. So write it with that in mind.
Learning how to use your IDE and tools. This to me resulted in a far greater productivity increase.
For examples:
learning how to use a source level debugger
using tools like purify/boundschecker
fxcop
etc. I realize I am dating myself, but those were big steps. There are many more.
Any time you can change the way you think about a problem or solve a problem without having to undo previous work is HUGE gain. Process, tools, etc all can help with that. Don't limit yourself to finding silver bullet techniques for productivity gains.
Watching productive people work and getting them to tell you what they are doing and why is also invaluable.
If I'm honest, using, and learning a great framework like .NET has really increased my productivity.
I'm often amazed what people are willing to reinvent due to their ignorance that the very same function already exists in the framework.
AGILE and especially Test Driven Development. Best thing to happen to software development since the invention of Object Oriented Design.
Concerning coding, I'd say design patterns and architecture patterns are always nice to look at and can help you write cleaner/better code.
For methodology I would advice Agile development that is great. There are a numerous number of techniques and methods (I'm personally fan of extreme programming) and reading that can keep you busy and improve your general approach.
Finally I'd say learn new languages like Ruby
Design patterns
SCRUM process
DiSC assessment (and understanding of how it applies to collaborative s/w development)
StackOverflow.com (of course!)
Google
... other stuff too, I'm sure
Design Patterns. Learning how to break dependence upon implementation and inheritance, and depending on interfaces (contracts) instead changed the way I think about programming.
Debugging. Once I figured out how to actually step through the code and go line-by-line, examining the underlying state, it revolutionized how I troubleshoot code.
Practice, practice practice: I didn't realize how important it is to keep working on my skills apart from work until a relatively short time ago. Mistakes and solutions I make at home make me a better programmer at work, and vice a versa. Learning should never stop if you want to be good at something, and programming isn't an exception.
If I had to pick just one, I'd say Test-Driven Design, aka TDD: write unit tests (and check that they fail) before you incrementally add features.
Try to learn to see things from the user's standpoint.
For example:
learn how to write meaningful error messages
learn how to produce usable applications
learn some basic speed-optimization techniques
Remember that the user sees your application, not your code.
VIM Quick Reference Card. After I started using advanced vim (macros, plugins) I have stopped doing any repetitive actions during coding manually.
Apart from that, Scrum and working at night, when noone interrupts You gave me the highest benefit.
If you want to expand your experience into web programming, you should try and get a good handle on the HTTP Request/Response paradigm. This will make creating web apps much easier on you because you understand the underlying framework.
(http)://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
I would look at some of the newer languages that combine OO and functional elements, like C# or Scala.
Learning Smalltalk has helped me become more productive. It is an easy language to learn and things can be built extremely quickly. For a stunning productivity aid check out Seaside, it's a framework for building web applications. Moreover, if you have only been used to curly brace languages Smalltalk will also make you smile!
I was helped by the following paradigms in this order:
1) bottom-up programming
2) top-down programming (C, Pascal)
3) object-oriented programming (Smalltalk, Java)
4) functional programming (lisp, Mathematica)
with some logic programming thrown in (prolog).
nHibernate hands down. The fact that I dont need to write database functionality for my business objects is very useful and time saving.
High level understanding, creating good abstractions with proper dependencies, is what pays off in long term. For example, Law of Demeter is an important guideline. I recommend also reading Eric Evan's Domain Driven Design
Code generators. They're the best thing in software engineering.
Would you like to write all your projects in asm? Nope, let's generate it from C++. Or from something sat above the JVM which diligently generates the necessary machine code.
Duplicating the same source code all over the place, but stuck with a language that insists on the line noise? Use macros.
Want to use lambdas in a language that doesn't have them? Work out how to fake the anonymous name and variable scoping required then generate the boilerplate.
None of the readily available languages quite fit your pattern of thought, desired syntax or even semantics? Write a compiler for a new one.
Better languages are nice. Better design patterns are nice. Emacs is awesome. But compilers are where all the power lies in our field. I suspect the only reason they aren't mentioned in any of the other answers is that we can't imagine programming without any.
Copy/paste technique