Sanjay G
Learning and facilitating to meaningfully learn, think, and 'create' ; also expand the context of computing.
How to learn the art of software? requesting to recall narrate personal experiences.
I am documenting the narratives of effective learning amongst software professionals. I invite the software engineers to recall and share those highly effective learning experiences that became a turning point.
Your experiences can help a lot in grooming the next generation. Thanks in anticipation.
Answers (15)
The most important experience I had was to write complete applications (GUI, processing, & storage) myself. Some (typically larger) companies keep people very focused on one aspect of an application, so they don't learn the bigger picture. With a background of writing complete applications, defining the architecture and writing modules is much easier.
As in all learning endeavours, failure is one of the best teachers. When you spend weeks building something and the night before you go live, you realize that it was wrong, you learn a lifelong lesson on how to do it right.
It is very important that software engineers have the "overall view". Very often we see developers work on just building a module and then moving off.
Seeing a product being actually used, after having seen it as an idea in someone's head is a very humbling experience. It is very important to have exposure to operations to know how your design decisions affect users in real life.
Mark M
CTO @ Dialed In, Inc., // Owner @ Silicon Chisel // CTO @ Find-a-Therapist, Inc.
Best Answers in: Web Development (2)
One of the most important things is to get developers to meet customers early on. Even if it's just manning a trade-show booth. Realizing that the folks who are calling in those annoying bugs are real people who you met in person changes the perspective a lot. It's just so easy to get cut off from the customer/user.
As a pure learning experience, nothing beats having to fix someone else's code. It's painful, brutal, and cruel at time - but it does force one to look at problems from the "outside in" for a change. Not knowing how it was intended to work, only knowing what it's doing wrong.
The most effective learning I have experienced has come in three ways.
First, "stealing" code that solves a particular problem, but customizing or modifying it to suit my specific needs.
Second, to struggle and struggle and struggle with a concept or a design feature, then have a co-worker walk by and say, "Well, have you tried _______?" If they had made the suggestion *before* I had faced the struggle, I may not have understood what they meant. But, having gone through the hard work of trying and failing myself, I would be in a very receptive state!
And finally, third, it has been a wonderful experience to learn how to simplify. The code that solves the problem in the simplest way is the best code... but it is sometimes difficult to avoid getting carried away, and adding "features" that did not come from customer requests! The lesson for me was to solve the customer's problem in a way that works, period. Don't improvise or elaborate, just do what the customer wants.
The best software people think at a higher level than languages or tools or interfaces. They imagine systems and communities and actors in their minds that interact and have behaviors. When I first put together a team, I put out problems we are solving in a vague sense. As people answer, I see who is operating at this conceptual level and use their comments and thoughts to elevate the group. I watch for those stuck at the tactical level, in the world of tools and languages, and I push them straight out of their comfort zone. Good code is important, don't get me wrong. But conceptual thinking is where the best engineers thrive. And so, to answer your question, I find that collaborative discussion is one of the best ways to train software people.
Links:
I think you really have to have an understanding of the fundamentals. This needs to be supplimented by a passion for this industry. If you don't love the work and are not engrossed in it, you will not make a good software engineer. I would also make an effort to learn about the history of software, how the industry came to be where it is and how the different processes of developing software evolved.
Find a mentor. Someone to help guide you. Formal learning only takes you so far. You also need a vision of where you want to be.
Read books, join a society, read articles. There is a lot to learn and it is always evolving and changing.
A good basis in the fundamentals, knowing where you came from, passion, a willingness to learn, being part of the community, a firm understanding of history and someone to guide you. Add a bit of talent and hard work and you are well on your way.
James M
Software Security Professional
Best Answers in: Information Security (4), Enterprise Software (2), Event Marketing and Promotions (1), Staffing and Recruiting (1), Planning (1), Professional Organizations (1), Professional Networking (1), Computers and Software (1), Software Development (1), Using LinkedIn (1)
The turning point for most is not in writing software, but in writing high-quality secure software. Most do this by attending OWASP meetings...
A agree that the best learning experiences come through collaboration.
For instance I am one of those developers who likes to read books on technology before diving in to coding, but I have worked with others who like to start writing code and see what happens, drilling down through intellinsense to find something that might work. Having both of these types of people working together helps both people learn, and not just learn the technologies; learn better problem solving skills. better software architectures, security models and much more.
Look into pair programming. Paring a junior level developer with a more experience developer can really bring a person up to speed quickly... it will also surprise the more experienced developer than he may have something to learn from the new guy.
Bugfix.
Bugfix is the more booooring experience that a software developer must manage, but from my point of view is the best approach to learn. Bugfixing is an activities that help me to understand a new system, and understand how my team think and work.
Working with QA engineer that hit your finger for every crash or weird solution, I could understand how different is the mind of a software developer and a customer.
A program is a big wall where a multitude of people left his particular feeling and experience so in every line of code I try to discover new way, trick, pattern, anti-pattern. And sometime I let my ego to overwrite some other graffiti :P
Another strong experience is when my older boss ask me to reduce the number of line of code for a software component. After a week of fitness and headache my component was a looooot more slim.
f.
Bob M
Senior Software Engineer at ACCESS Systems Americas, Inc.
Best Answers in: Software Development (12), Ethics (9), Computers and Software (8), Air Travel (1), Hotels (1), Travel Tools (1), Education and Schools (1), Mentoring (1), Government Policy (1), Staffing and Recruiting (1), Exporting/Importing (1), Offshoring and Outsourcing (1), Small Business (1), Information Security (1), Web Development (1)
I hated it when I was first doing it, but the best thing I ever did was maintain and improve code other people wrote.
My first couple of jobs as a programmer involved writing code from scratch, and I learned a lot and accomplished a lot, but also developed a big ego.
Then I got a job working on AutoCAD in the late 80s, and that was a real eye-opener! I was constantly looking and code and thinking, "What the #*%& is going on here?" and then having to figure it out.
Here's what I learned:
1. I wasn't such a hot programmer as I thought I was.
2. There are a lot of ways of solving a programming problem that are not immediately obvious.
3. There are a lot of ways to use programming languages (in this case, C) that are also not immediately obvious.
4. It's a skill worth cultivating to be able to walk into the middle of some gigantic piece of code (in the case of AutoCAD, millions of lines of C) - so big, you can't possibly understand it all - and still be able to figure out some chunk of it and make a useful contribution without breaking everything else.
5. If you're writing cross-platform code (AutoCAD in those days ran on DOS, SunOS, MacOS, and a whole host of odd Unices), there are a lot of things you have to watch out for.
I would highly recommend it for anybody.
Debajyoti B
Architect at IVOX Inc.; Technology Specialist at NIIT Technologies Ltd
Best Answers in: Software Development (1)
I read a small PDF in 2000 called Design Principles and Design Patterns by Robert C Martin that changed my outlook forever.
It is still available, look at the link below:
many thanks
~DeeBee
Links:
There are a couple of people at work that I consider mentors. I try to "pick their brain" every chance I get.
Other ways to learn:
Read developement blogs (Scott Guthrie, Scott Hanselman)
Read developement magazines (MSDN, CoDe)
Read developement books (Code Complete)
Listen to Development/Tech Podcasts
Attend Development User Group meetings
Hope this helps.
Links:
Clarification added July 7, 2008:
Most of my experience comes from being under pressure. I tend to learn some by just doing research, but when your under pressure to get something done and you are thrashing -- that's when you learn the most.
Kumar L
Member Technical Staff at Adobe Systems
Best Answers in: Education and Schools (1), Career Management (1)
As any other art, one should first develop the appreciation for it. One should look at famous/popular/critically acclaimed (similar) work of art and understand why it is better than others.
I started off with looking at the tons of open source code on the internet, not only one learns the technicalities of it but also starts to understand the different conventions that good "software artists" follow.
Software is not that different after all, the problem lies (probably) with us not being able to find correct analogies with other matured disciplines. For example, let us pick up language. When I was learning how to write in English, I was not given a ball pen to start with; I used a pencil for many days, then ink pens were made available. Elders around me suggested not to use a ball-pen if I wanted my handwriting to be good. A good handwriting makes your work better presentable, readable and hence understandable, extendable. When we write a piece of code, there is no way our handwriting can go bad because we are typing!!! However, the correct analogy would be to write better structured code and there are many guidelines for this.
The first step would be of course to replicate good works that has already been done, followed by the inspection for "scope for improvements" where improvement is a multi-dimensional word. Then extending existing art-work to achieve more of what is already there.
The major second step is to conceptualize and design an art-work. I don't think you deserve to make a blue-print from scratch if you haven't seen a blue-print being implemented (into a building). This design work must be followed by an implementation project of the same design, this way you know that every line on the blue-print means so much of time, money and effort. Also, the problems one faces because of a faulty design and concepts, are understood this way.
Once you know how to write stories (in one language), you can start learning new languages and write stories in them too. The words you use, the sentences you form may be different but the moral of the story remains same. The language used for narrating the story will only determine the audience, not the story.
I have always found strong correlation between other disciplines and computer science, more with art though as it deals with creation. While starting off with software, if one tries to do the exact same things that he did while starting with English or Mathematics; he would find that its not that different. You just cannot learn software as an extension to any other subject. Like physics, chemistry, mathematics, concepts can be shared back and forth but one has to start it from scratch and take it in parallel to all others.
PS: This is not directly a narration of my personal experience but pretty much the gist.
Mark Miller is straight on in his response of how important it is to have developers meet with customers early on and also how a lot of software development know-how can be derived from working on someone else's code. Customers, both technical and non-technical in many cases, usually know what their needs are or at least can be made to think their needs through and define to you (the developer) what they want from you.
Early on in my own career, I worked in technical support on the Borland advisor lines assisting people who were writing their own software using the Borland and Turbo C++ tools. Those of us who were working those lines, learned a lot about software development and customer needs due to a wide variety of problem types that we would encounter every day using many different software development technologies (from C++ to HTML to Assembly Language) on operating systems from DOS to Windows 3.x, Windows 9x and OS/2. (I'm dating myself now.) I personally believe that a good software developer is in touch with the needs of the customer.
I also believe that looking at and fixing another person's code can be a good tool for honing your own software develoment skills.
The software developer who does not believe that there is anything left to learn or that he cannot derive any more knowledge from others is the same software developer who does not realize what he does not know.
Back when I worked for Borland, I was constantly fixing other people's code and I learned more in that job than I had learned in four years of college obtaining my degree in computer science. There is a lot to be learned from other people which is also why people still google software development solutions and why some developers perform code reviews of software every day.
I also agree with Jeff Hall that pair programming is a very useful tool to facilitate developers passing their knowledge to other developers, QA staff, etc.
Clarification added July 7, 2008:
I also wanted to add, that like in anything else, expertise comes by gaining knowledge and then putting that knowledge into practice. Oftentimes, it is more important to know where the information you need is located or how to derive the information than it is to know the information itself. Lastly to master anything you need to sometimes let go of your knowledge (or what you think you know) and go with your instincts (which are derived and honed by experience).
I'm reminded of the old joke about a couple visiting New York for the first time. They see a down and out man playing violin for passers by, and they ask him if he knows the way to Carnegie Hall.
The violin player sighs and replies, "Practice, practice, practice."
The many answers so far demonstrate a variety of paths to the goal, but in the end the key is experience. As much and as many as you find.
For me, the best technique is to throw myself into the deep end of the pool. You WILL learn to swim! (Or not, in which case it's rather moot. :-)
Specifically, I learn new languages or systems by developing something interesting and non-trivial in them. It's a steep climb, but effective.
