In art school, they get taught how to do what we call "construction" - how to think of things as three-dimensional objects rendered onto a flat plane. Their process becomes full of boxes and cylinders and perspective guides.

Grizzled pros just draw stuff without thinking. Because they've done the construction so damn much it happens beneath the level of consciousness. I only need to construct every now and then, for tough, rare angles. Someday I won't have to do that any more either.

I'm not really sure I'd call it "the same place". It looks like it from the outside, but I'd describe it as more like a full turn around a spiral staircase.

"And the end of all our exploring - Will be to arrive where we started - And know the place for the first time."

BTW I strongly recommend that film -- it was fascinating in so many ways.

So much of what you see is exactly the same - the places you used to hang out at, your family and friends - but the lens through which you look at it is completely different.

You start as a beginner by reading books, watching experts, taking a class. Even if you start by jumping in and figuring it out, you still get the notion of how you should do it from somewhere. Because there is too much theory to understand at first (be it music, computing or math), you accept dogmas, or theorems or theories and work with them.

Eventually you gain enough confidence to reconsider what you have been taught. When you do come full circle, I think it's mostly because you understand why something is taught the way it is, not necessarily because you were instinctively doing it right at first.

After say 5 years I understand what he was saying to me know. Patterns are patterns, they implement themselves when you need them. All you need to know is how not to do it badly. You shouldn't be trying to implement patterns if you don't need them.

I know its a high horse position, because you need to go through a phase of using them to understand why they aren't a miracle cure. o I find the the growth/education of a programmer some what similar to the articles notion.

For reference any younger dev out there that looks at the work senior devs and thinks to themselves "why are they senior? there work is obviously rubbish", you'll probably end up that senior dev one day.

In my experience most senior devs have been like you... perfectionists, aborbsed with the latest greatest etc... and you learn over time all that really matters is delivering on time, code management, and getting burnt by the latest and greatest really sucks.

So you slowly stop writing over engineered code. That often means doing things a basic way, so people in the team aren't left behind that don't understand, understanding your code isn't that critical... whats critical is finishing on time, that optimisation is the last thing you do because it takes to long and you really don't know if what you are writing deserves so much attention (i.e. if it takes off revisit the code, if a choke point starts appearing then optimise). Basically don't waste time on problems which don't exist, don't create stress for yourself/team/management by over engineering solutions.

Next time you wonder why a senior dev seems to be hopeless ask them why they choose to deliver a solution like a beginner and maybe you'll learn something invaluable ;)

That has been my understanding. I consider that the only practical reason to review design patterns is so you can communicate the style of code to another.

After a while as you program you look through the code and see the needed meaning, shaping the code to conform to the meaning better.

That guy was pretty damned sharp, worked long hours, researched implemented push boundaries, and delivered some stuff I'm still proud of. But he had something to prove, he put meaning into things that didn't want or need meaning. Over engineered everything.

But a calmer/mature more strategic me says I don't need mavericks on business automation software. I'd be watching me like a hawk, because I made mistakes, big ones from time to time (my favourite was a system failure costing €50,000 in lost revenue... all my fault, I was literally told to clear my desk and was marched out the door).

You need those mavericks to push boundaries, its fun to be one, but boy its disconcerting when you have one in your team and all you need t do is deliver is a CRUD application.

I wish we shared more of these tales of mistakes. It seems to me that the current software development environment involves an attitude of shame over mistakes or simple ignorance, to the point that it becomes a political battle simply to get a developer to admit fault. The only place I know that discusses mistakes would be something like the Daily WTF, where snark and condescension are the name of the game (not that I don't enjoy reading it...).

I become a fan of agile for that reason. I found agile created "chummier" teams. I don't think it made for better project delivery, but I did find having a morning meeting made risks apparent and made people more confident to raise issues before they snow balled, and people didn't blame each other the same way. Discussion/communication is basically everything to successful delivery in my books.

I picked up a neat pseudo meeting trick I use every day now (even in big water fall projects). I go for coffee down the road. It takes like 15 minutes and the benefit well outweighs the negative.

The benefits being a casual discussion abut whats going on where people say things they probably wouldn't normally. Its best to weight till after everyone has done there morning emails, so maybe 30-60 minutes in then the gossip gets going. The amount of spite I have heard spewed about clients/vendors/colleagues you wouldn't hear otherwise is astounding. Its the casualness of the walk and cafe that lets people vent. But you have to get out of the office, you have to get away fro the structure, and away from people that may over hear the criticisms.

Also its not about a team meeting, people won't come and blurt out whats really on there mind if they think its going to get recorded and itemised. Remembering if they have read/replied to there emails before you head out. Then thats mainly whats going to be no there mind, they will bring up the problems because they are at forefront of there thinking. Its all about keeping things casual.

On the other days when things are running smoothly you get to know them more on a personal level, talk about there kids, cats, skiing, what ever. Just casual gossip and of course its team bonding. When you get to know people a little better it makes interacting with them easier, raises issues/problems etc.. isn't going to be such an assault on someone. Even just the effort of inviting someone that doesn't drink coffee goes along way.

Can't recommend it enough.

I distinctly remember scoffing at the old stagers for not getting onto the latest and greatest bandwagon.

I certainly hope some of my early bloatware has died it's natural death.

To their credit I was often indulged with my acronym love in the early days by the old stagers. I guess they see it as a process you have to go through, and if they see potential, are willing to let it slide with only a couple of pointers.

Get back to basics. Deliver results. 80/20 analysis on everything that you do. Don't ever insert an abstraction layer until you can explain to someone within 30 seconds where the true business value lies in that layer.

٭) The app's controls look simple and grayish like in Windows 2K. No color effects. No translucency. No skinning. This is an app that dozens of people use on a daily basis and it makes an effort to let them do things fast and accurate with the least chance of surprise and/or annoyance. No user of the app has complained to me yet about the lack of eye candy; they do appreciate snappy response times, tho ;-)

Now I'm hyper-pragmatic and feel like I've plateaued somewhat as a developer - I'm producing systems that work well and fulfill clients' needs but I'm finding building them isn't the exciting challenge it once was.

Where now?

Personally I’m also interested in deductive databases and ontology but, on the whole, those are too ambitious even for academia these days, which I think is a shame because to me logically organizing information is probably one of the most important problems in IT since the web was created.

It seems that a good prologish system could solve large classes of "business rules" problems pretty easily.

So what I think is the solution is to go meta. Step back and ask why you're having to write the same code to pump out the same kinds of apps. What is the commonality between all the various apps you're writing? Now solve that problem. The ultimate iteration of this, if done successfully, is a system that takes a design plus a formal specification of an app's functionality and automagically makes it work. Now you're working at a higher level of abstraction. I don't yet know what happens when you get bored of that. Perhaps by then you'll have developed your own AI.

No, I think you're maintaining the abstractions you built before that point. Look at all the frameworks that get developed for many years before they're abandoned.

1. http://aichallenge.org/

Obi-Wan: Your father was seduced by the dark side of the Force. He ceased to be Anakin Skywalker and became Darth Vader. When that happened, the good man who was your father was destroyed. So what I told you was true, from a certain point of view.

Luke: "A certain point of view"?

Obi-Wan: Luke, you will find that many of the truths we cling to depend greatly on our own point of view.

--

Perspective is infinite -- only the omniscient see its entirety. But we often believe that our perspective is the way things are. The whole truth.

Humility is the key to not being limited by what we think we know. "We can't learn to see until we realize we are blind." -- Alan Kay.

Unconscious incompetence -> Conscious incompetence -> Conscious competence -> Unconscious competence

http://en.wikipedia.org/wiki/Four_stages_of_competence

"Beware of the man who works hard to learn something, learns it, and finds himself no wiser than before. He is full of murderous resentment of people who are ignorant without having come by their ignorance the hard way." http://www.quotedb.com/quotes/3786

I think.

"Beginning musicians play by ear, to the extent that they can play at all. Then they learn to read music. Eventually, maybe years later, they realize that music really is about what you hear and not what you see."

Reading music is also a way of learning a piece, and for complex music (i.e., most classical music) it is the most effective way of learning music quickly, even if you're the most advanced player in the world.

I would contend, however, that "they realize that music really is about what you hear and not what you see" is not just fluff. Intermediate to advanced players are frequently very tied to the page. They tend to think in notes and barlines, which is a reflection of intermediate level training that usually focuses on rendering literally what is on the page. One of the big advancements that musicians tend to make at conservatory is to learn how to think in audible units -- phrases and gestures -- rather than the visual units they see on the page. So yes, expert musicians do rely on their ear in a way that they usually do not at intermediate level. However, it also has nothing to do with the way untrained beginners use their ear, as a way of learning music.

EDIT: A more useful analogy for musicians would be to look at how they approach the physical aspects of playing. In the beginning, a string player is taught to move the bow by moving their arm back and forth. Once they get the hang of this, they spend a decade or so dissecting the fine details of that movement: fingers, wrist, elbow, shoulder. Making the bow change directions becomes a complex dance of many choreographed movements. Eventually, though, it all becomes second nature. When an expert thinks of moving their arm back and forth, it is a shorthand for all the things they've internalized about how to use the bow.

This is similar to the martial arts idea of learning technique and then forgetting it. It is most emphatically not, however, coming around to realize that your original conception of how to play was more right than what you were doing as a journeyman.

The remark on Dirac delta functions resonated with me, although I feel as if I have actually go through several cycles of enlightenment and ignorance. Actually, I get this feeling for most topics in analysis in general.