Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

(OT) Programming as a craft

by revdiablo (Prior)
on Dec 16, 2003 at 00:46 UTC ( #314940=perlmeditation: print w/replies, xml ) Need Help??

Hello once again, my fellow Monks. Before I get started, I feel I must confess that this post is vaguely off-topic. Furthermore, I have not done any research on the subject. Perhaps it is covered extensively elsewhere, and will be redundant and boring. I present simply my thoughts, with the hope that they might provoke some interesting discussion.

Last week I stumbled upon an inconsequential quote buried in my [nearly pointless] Principles of Management textbook. I do not have the exact quote, but it was about outsourcing, and referred to programming as a low skill occupation. This caught me slightly offguard, but then I thought about a growing (to my eyes) number of people who consider programming a craft, rather than a science.

It made me think about other crafts, and the connotations that come with them. To me it seems that "mere crafts" are often delegated to a lower status than other occupations. Consider a carpenter or mason. While a large amount of skill is not required to perform these jobs at a basic level, the skill demonstrated by those who do the job excellently can range from high to masterful. There is a continuum of skill here, but, in my experience, many people on the outside focus on the lower end of the continuum.

It seems to me that programming a computer is becoming something like this. There are those with a level of skill that is barely adequate, and those with a level of skill that is simply amazing. I wonder if this will continue to become more pronounced, or whether perhaps it has been this way the whole time. Maybe it is something that's always been there, but I am only now becoming aware of it. In any case, I think it is useful to at least consider the continuum. This should leave some of us free to reach for the higher levels of craftmanship, while also helping remind us not to be contempuous of those on the lower end. After all, someone must build the tract homes of the software universe. 8^)

Another interesting aspect of this analogy is that it leaves a place for those who would rather call themselves a Software Engineer than a Programmer. There is plenty of room for both Engineers and Craftsmen, even on a single project. Maybe in the future these will become altogether separate jobs in the software world, and this will be a good thing. This might already be the case. I do not have extensive experience in the software industry, but it seems, from the little I do have, that Software Engineer and Computer Programmer are essentially synonyms, even if the former perhaps sounds more important to a certain portion of the population.

Again, I submit this might be pointless and redundant rambling. Perhaps I am pointing out things that are blindingly obvious to most of you here. If so, there is likely some other aspect to this picture I have completely missed -- please share! I guess I wrote this in a somewhat selfish attempt to gain insight by the replies of more experienced Monks. Hopefully it will bear fruit...

Update: thanks to simonm for the catch. changed "track" to "tract"

Replies are listed 'Best First'.
Re: (OT) Programming as a craft
by Coruscate (Sexton) on Dec 16, 2003 at 01:20 UTC

    Programming can be looked upon with multiple views. It depends on the person who is doing the programming, as well as the motivation that person uses when doing the programming.

    There are several ways to look at what 'programming' is. First off, it can be seen as nothing more than getting a computer to do what you want: quick and dirty is all that counts. Just get the job done and then forget it. You might call this the 'programming job description'. On the other side of the fence, you might see programming as an artform. It is possible to spend a great deal of time dealing with one software 'problem', sorting through various solutions before choosing the one that fits the situation best. This might be something we could call the 'programming art'.

    When I think of programming as an artform/craft, the first thing that comes to mind is code that exists that does not really have practical real-world use. Obfuscation for example, cannot really be looked upon as part of a job description. It is a hobby and most definitely a form of art. Golfing has recently become a bigger thing as well. Taking one task and writing the version containing the least number of keystrokes to execute. Golf tends to start with an 'ideal' or realistic version that you might see in actual production code. As it progresses, the code evolves into obfuscated code.

    This whole idea of programming being an artform really does not just exist within the IT industry. Any job can be transformed into a crafty job, it all depends on the individual or team involved. Those who see their jobs as an art rather than just a job are (IMO) most likely those who have been working the area for quite some time. They've learned to evolve beyond the find-the-fast-solution-and-move-on methodology to a higher level of work ethic.

    Oh, not to mention that an artsy job is much more fun and pleasant than a boring do-the-job type of job :)

Re: (OT) Programming as a craft
by BrowserUk (Patriarch) on Dec 16, 2003 at 04:18 UTC

    I drew my conclusions on this subject when it came up once before, and nothing has changed in the meantime except that I ended that piece with

    Hopefully, that will remain the case at least until after I retire.

    A change of mind, or maybe heart

    On this I have changed my mind. Over the intervening year, I have had the time and motivation to look at where I think we are on the evolution of both the business and the profession of software development, and I have reached the conclusion that not only will it's current 'craft' status change -- it must change.

    Despite my natural reluctance to see the end of what one might emotionally call 'a way of life', the one I have pursued with interest and fun for 20+ years. I now see it's demise as not just inevitable, but desirable. Whilst I previously thought that I might get away with being a Luddite and basking in the glory of the 'lone craftsman' persona until I retire. Thanks to having had the time and motivation to take a look at specific aspects of what we do every day as programmers and look at them in detail -- something that as a working programmer I had never had the time to do before. Not just 'performing the functions of a programmer', but looking closely at how the methods we currently use, evolved, and where they might lead to if pursued (with some hopefully intelligent guestimation and projection) into the future a ways.

    A tentative conclusion

    I've reached (a tentative) conclusion that we, both collectively and individually, are on the cusp of a major leap in the way software development is both performed and it's status as a result. The change I foresee, might be called, for want of a better term, automation.


    Just as with so many other mass-market products that start out being manufactured by small groups, usually driven by highly motivated, and not necessarily "professional" individuals, the transitioned to mass manufacture by a small number of very large corporations in order to achieve the benefits of scale required to fund the huge R&D costs for 'new models' is inevitable. That will probably not be a popular conclusion. The chances are that those with a little knowledge of history will envisage software moving into the 'production line' phase, with the inherent horrors of individuals performing endlessly repetitive, menial tasks in lock step. With all the skill, flair and therefore interest diluted or completely removed. Like an auto-manufactures assembly line. I too used to think that this was the next step on the evolution.


    After all, this was the case in so many other industries. And not just the obvious examples either -- the auto industry, motorcycles, TVs and other electronic consumables in general, even the PC. With a little sideways glancing at many other industries, you can also follow this progression. Tourism & air travel, with package holidays, mass-market cruise ships following each other on the same schedules just far enough apart that the wake from the preceding ship doesn't 'shake the contents'. A little harder to see are things like music, film, fashion and even art. However, I think that there is a major difference that means that all is not lost. The older of the above industries have moved beyond the assembly line stage, with thousands of people arranged either side of a moving conveyor performing repetitive tasks like automatons. They have been replaced, by automatons -- robots. The driving force behind that replacement was costs, mostly labour costs. The enabling technology that allowed the replacement was computers. These gave the machines that actually performed the task of assembly, the intelligence and dexterity to perform those tasks without the guidance and supervision of the human brain. This is the same technology that will (IMO) allow the software development industry to bypass the assembly-line-powered-by-humans stage and move directly to the automated assembly line stage.

    Essentially, the craft-to-assembly-line transition involves breaking the task of overall assembly down into infinitesimally small, discrete steps and then assign each step to an individual (human), to master and repeat endlessly. The enabling technology for this in the mechanical engineering field was the use of the basic had tools of that craft -- scribes, rules, micrometers, hammers, saws and files -- to be used to create better machines -- lathes, routers, presses etc. Once this was mastered, then it became possible to create specialist versions of these machines that would produce sub-assemblies that the individual workers then assemble together to form the final product. This is roughly where we are today in the software industry. We have the second level of tools at our disposal -- editors, compiler, interpreters, version control, CD burners etc. With these, we can produce the software sub-assemblies, classes, libraries, objects etc. The industry is now trying to get to grips with the mechanisms of utilising these sub-assemblies in production line environments -- the moves towards offshore software development are the current signs of this although there were plenty of corporate MIS depts. that attempted to do this kind of development throughout the 80's and 90's. Assuming that throwing large numbers of programmers at tasks, under strictly controlled development team regimes would result in quicker development times and reduced costs and reliable time scales. Personally, I think that both of these strategies will eventually be discredited and discarded as failures. And not before time. The next step is robots.

    A ray of hope

    I can sense (or pre-sense) the hostility that many who read that statement with feel. They, like me, do not want to give up their job, their skills, their art, their passion to a robot. Fear not, you won't have to. The reason is that, as yet, we have not for the most part reached the point where our jobs can be automated, not even by computers. More importantly, we have not yet reached the point where the numbers of people employed in the industry and their total salaries have become such a high proportion of the total available income from the potential market for our products, that they govern the profitability of the industry as a whole. With cars, the markets where pretty much saturated in terms of numbers somewhere in the late 80's, early 90's. As such, the only ways to get higher profits was to

    1. differentiate the product to induce brand switching.
    2. reduce unit costs -- ie. reduce staffing levels.

    The software industry is far from reaching this point. In fact, the limiting factor in the applications of our products is our ability to produce them. There are a million new uses that software could be put to, and the new markets and uses grow every day, as the hardware gets cheaper and more powerful.

    The limitation that stops the field growing is the productivity of the industry. It simply takes too long, using current techniques, to bring new products, or even better versions of existing ones to fruition. During the 80s and again in the dot Com bomb of the late nineties, as the market place for our endeavours grew, the attempt was made to ramp up production by increasing productivity through assembly line programing and by recruiting large numbers of low-skilled personnel into the industry. Both failed.

    History's lesson

    The lesson that can be learned from history of other industries is that the only, long term, effective way of increasing the productivity of an industry, is not to dumb down the job and throw bodies at the problem, but to increase the skills of the existing levels and have them develop tools that perform the mundane and repetitive parts of the process. A small number of highly skilled personnel use their skills and innovation to automate those parts of their jobs that they hate. Universally, the boring and repetitive parts. The number of people employed remains static, but the education (and salary:) levels increases as they use automation to multiply their productivity. I recently typed the following in another post here

    A secret

    The secret of productivity is to have tools that do more of the work, more quickly, more accurately and with less supervision. Computers, as tools, are being applied in every area of human endeavour to this end with amazing results. With one, notable and lamentable exception -- software development.

    I repeat it, because I don't think I can say it any better. I think that this is not only the indicator of what we in software need to do, I also think that the time is nigh when the technology, the motivation and even the financial climate are such that we will be able to do what it necessary. And that is to produce better tools. That doesn't mean better editors, or faster sort algorithms, or easier to use versioning systems, or more testing, or bigger, more comprehensive code libraries. It involves the integration of all of these and more. We need tools that automate steps, and facilitate that automation. We don't just need a bigger parts catalog. We need tools that know about the parts catalog and help use to select the right parts from it. We need to be able to select not individual parts and glue them together, but to be able to specify the purpose of our applications at a high level and have our tools select the appropriate parts for use and integrate them together for us. We need to be able to interchange parts on the basis of performance as measured by any of several criteria and pick the one that supports the particular performance characteristics required by our application.

    We specify a sort. If the application requires a faster one, we swap in a faster one, or a stable one, or one capable of handling large volumes of data, or one that is specialised in dealing with the particular attributes of our data -- transparently to the rest of the application. Perhaps the application can select the sort it uses on the basis of real time intelligence of the data it has to sort. The tools, and even the applications themselves have to become more intelligent in selecting the building blocks they use to perform the tasks at hand, given real-time intel on the nature of the data upon which they must perform it.

    Ultimately, this probably requires more intelligence in the software that runs the tools and the applications. Ie. The OSs themselves. We need to move beyond the current crop of models of the world and the data in it, which evolved in the 1970s and 80s to model the world in terms of the architectures and hardware, and their limitations, available at that point in time. Higher level languages is one part of this. The integration of those languages with data stores that don't reduce the world to a series of bytes streams is another.

    Exciting times (I hope)

    In many ways, I see this as the most exciting time in software development. Watching the tools and systems that will integrate the innovations of the human mind with the power of the hardware now available to us, will be a privilege to witness. If I can find a way to take part in the process, so much the better.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail

      That argument ignores a fundamental difference between software and manufactured goods:

      Duplicating software is easy.

      A compiler and a copy command are your assembly line; it's already fantastically cheap.

        It's a fair point, but I wouldn't say that I ignored it, just that the terms of the analogy require reinterpretation to 'fit' them to the reality.

        A compiler and the copy command are very cheap, provided everyone who wishes to use your product has exactly the same compiler, and cp er.. copy command, but they don't, nor should they. Once you move out of your 'production plant', the effort required to copy and compile the product start to rise. Perl itself runs more places than almost anything else you care to name, but at what cost?

        A Config that contains a little under 1000 variables.

        A build process that, to be frank, makes the assembly instructions for your average automatic gear box, self assembly PC, even a full blown kit car I once assembled, look relatively simple by comparison. So complicated in fact, it is necessary to distribute and build two copies of perl in each dstribution. The first is a simplified version with just enough functionality to ease the problems of configurability, so that it can be used to glue the many other tools, configurations and utilities that are required, be used to build the full product.

        The alternative approach is the packaged software route as exemplified by MS. With this, each application has to be pre-built to cater for all possible eventualities, and will only run on a very limited subset of target environments. Each application becomes enormous with the weight of its runtime configurability, despite the fact that late binding is available and that 'they' control the content and functionality of the environments that they target

        If 'production', in software terms, meant the copying of the code (compiled or source) onto a CD (or server) and distributing it, then that indeed is cheap. However, it doesn't. Most manufactured goods leave the production facilities as finished products ready for immediate use. Software, even the best packaged consumer software -- which currently probably mean games -- is rarely "ready for use" as it leaves the production facilities. Even most games require a certain amount of expertise and knowledge on the behalf of the purchaser, in order to install them and set them up for use. Except for those that run on proprietory, single function hardware where the variables can be much more tightly controlled than with general purpose hardware. Eg. PCs.

        Currently, software manufacturers leave the final assembly, tuning and shakedown of their products to the purchaser, and the costs of the training, expertise, man hours spent performing that final assembly -- and correcting it when it goes wrong -- are rarely considered along side the purchase price, except in highly dubious 'true cost of ownership' surveys.

        So,whilst the anaogy leaves much to be desired, if you extend your thinking to encompass the complete process from initial concept to ready to use, the differences becomes less clear cut.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail

      Indeed, the automation of programming is still quite far away in time, so it seems. I have witnessed two such attempts first-hand.

      I once worked for a company that had two departments (this company ceased to exist over 10 years ago). The department I worked in, produced CBT (Computer-Based Training, or courseware, or Computer-Aided Instruction, etc.). The other department worked on designing AI (Artificial Intelligence): they made systems designed to create AI-applications, and they tried to produce AI-end-user-apps.

      The European Community subsidised this AI-department with enormous amounts of money. Some spin-offs of their activities became mildly succesfull, like an application to support decision making. They used LISP to build their AI-system, and argumentably they did that in such a way that the applications could never be fast nor maintainable; that decision-making-support-application was horrendously slow. So they turned to the CBT-department, working with TenCORE (nowadays a dying language). The application was completely rewritten in TenCORE (liz did a lot of that work), after which the speed was acceptable. The app could be used to decide on e.g. the holiday destination for a family, using as many factors as that family wanted. As said, the app was mildly succesful, but it never was succesful enough to make up for the many EU-investments.

      This AI-department tried to automate programming. And in the end, they failed, and very soon after the EU stopped investing, the department vanished. Their tools were too simple for so complex a task, their goals too high, and they produced hardly any end-user apps.

      Back to TenCORE. That was the second attempt on itself. The creators of TenCORE made a system built on TenCORE itself, TenCORE Producer. Producer was just a higher programming language, simplified, made accessible in a GUI. Hardly any AI in it. At the time, there was also Authorware, built in C. Just like developers with Producer could extend their end-user applications with modules built in TenCORE, CBT-developers using Authorware could use C to extend their apps. By the way, developers used TenCORE and Authorware to create websites, multimedia, games (my company used TenCORE to create and maintain hundreds of websites).

      CBT can be considered as automation of education. Producer and Authorware can be considered as automation of programming this CBT.

      And why didn't this type of programming conquer the world? Because they are just tools. And there are a lot of other factors that influence success or failure, factors like marketing, economical growth, hype-ability.

      Creating good software is a lot like writing good books. Or like good project management. Or like good management of a company. You can have as many good tools as you can find, afford and use, but still the tools make the job easier, they don't do the job, that is done by the people that use the tools.

      Because of their complexity (both from a conceptual point of view and the implementation aspect), I think CBT and AI are not merged yet to be used succesfully world-wide. This complexity is not just a problem for the programmers, but certainly as well for managers, marketing people and end-users.

      Attention was drawn from the further development of AI in software development because the arrival of new hypes in the nineties, first multimedia, later internet.

      Now, there is a lot of simple (!) multimedia on the internet. And a lot of simple CBT on the internet. Even a lot of CBT combined with multimedia. But they all lack AI. I even see that most of this "modern" multimedia and CBT is simpler than what was produced 10 years ago (well, except maybe the games).

      I am convinced that Perl-specific graphical editors (like Producer and Authorware) would help Perl (just as it would be the case for other languages, like PHP, Java, Javascript, Python) to become more widely accepted as tools for development for software (not just internet scripts). But I don't know about such graphical editors, and I certainly haven't seen any such editors with AI-qualities.

      I think it might be a good step in the good direction when someone builds such a graphical editor in Perl for Perl. It should be easy to use, and it should enable a developer to build applications (CBT, multimedia, database management, computer system management, content management, etc.) without having to know much of the underlying language, Perl.

      Next step would be to add AI-techniques to it, so a developer would just have to give the program a description of the app to create, a lot of paramaters and a lot of contents.

      The first task of that program would of course be to build courseware to explain the use of the program and the underlying concepts. Because the developers need to understand the thing they are working on/with.

        think it might be a good step in the good direction when someone builds such a graphical editor in Perl for Perl . . .

        Perl is highly non-trivial to parse, which is why a any Perl IDE will have a lot of problems, even for jobs as seemingly simple as syntax highlighting. So I think this is another thing will have to wait for Perl6, where parsing should be easier.

        What I don't understand is why a Perl editor should be written in Perl itself. You're ultimatly dealing with a stream of bytes, which is as a completly language-agnostic concept as you can find.

        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

      The secret of productivity is to have tools that do more of the work, more quickly, more accurately and with less supervision. Computers, as tools, are being applied in every area of human endeavour to this end with amazing results. With one, notable and lamentable exception -- software development.

      Interesting quote, but I disagree completely. The proof of my disagreement? Perl it self (and dozens of other 'higher level' languages of course). What else is Perl but an attempt to produce a tool that does more of the work, more quickly and more accurately with less supervision? It has high level features built in, such as scalars and hashes to do more of the work which directly translates to faster, and it has a built in garbage collector to do stuff we as programmers don't need to supervise.

        I agree entirely that Perl is a step in the right direction. However, the language is only a part of the problem,and only a part of the solution.

        If you could write all your applications without recourse to an editor, version control software, a browser or other software to access CPAN, a datbase, test tools and all the other tools and utilities that the average perl programmer uses to write his applications, then I would agree with you, but you can't.

        Or at least, you can't do it that way and expect to produce a high quality product, that meets or exceeds the requirements, on time, within budget, at the target cost and that will contniue to perform it's function with reasonable maintanence costs for a sufficient period of time that it will produce a positive ROI.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail

Programming Versus Engineering
by chromatic (Archbishop) on Dec 16, 2003 at 04:28 UTC

    This is a reasonable and interesting question. Hopefully it will produce much good discussion. Now to throw some fuel on the fire:

    Where, exactly, is the "engineering" in software development?

    Is it design? No; craftsmen design.

    Is it gathering specifications? No; craftsmen gather specifications.

    Is it meeting deadlines? No; craftsmen meet deadlines.

    Is it knowing and using tools well? No; craftsmen know and use tools well.

    Is it repeatability? No; craftsmen repeat their results.

    Is it invention? No; craftsmen invent.

    I don't want to set up a strawman argument here, so I ask again: where is the engineering?

      A homeowner hires a carpenter to build some kitchen cabinets and they come out really nice so the homeowner asks the carpenter to design and build a housing development. Me, I'd prefer to have an architect and a planner involved. Can the architect or the planner build kitchen cabinets? Probably not. The carpenter is good at the specifics and might or might not know something about the big picture and the architect is the reverse.

      Some programmers are like carpenters and some are like architects, but most I know burn the candle at both ends - we like to think big and plan out all sorts of swell high level object manipulations and software interfaces but we also take pleasure in polishing off the corners on the indents and the idioms in the code itself.

      But society doesn't like these things mixed. According to THE RULES (sorry, I lost the URL for the rule book) the specifics should be left to the low level drones. Higher level managers should only concern themselves with the big picture. This means that programmers get treated like craftsmen regardless of their skill level and managers ignore the programmer's planning advice as too specifics-oriented to be real planning.

        I'm not sure I follow your analogy.

        Craftsmen build things? Non-craftsmen don't build things? Craftsmen don't plan? Architects aren't good at specifics?

        What if you hired a painter to design your housing development? Would he be as bad at it as your carpenter might be because a painter is a craftsman? Can an architect not be a craftsman?

        Let me be specific: I believe that the source code is the design. Compiling is the manufacturing. Engineering is, what, measuring the tensile strength of a stable quicksort algorithm?

        I think this is what I was getting at. I get the sense that the different types, maybe they can even be called factions, of programmer are slowly diverging. I'm not a historian, but I have an inkling that this mirrors similar trends in any newly emerging industry.

        There is a difference, though, that it seems chromatic has been trying to articulate: software plays by different rules, because it is not tangible. It's generally not practical for the person drawing the designs for a housing tract to actually build the houses, but with software, the code is the design. The design and the implementation are essentially the same thing. Sure, people have come up with many methods of planning and designing software before the code is put in place, but at this stage in the game the code is the blue print. The planning and design that goes on in the software world is very general and high level. The true design, in the real sense of the word, is in the code.

        I think this might change in the future, as we keep going higher and higher level, but even then it won't be the same as with physical production. The intangible nature of programming just makes it different. Perhaps I am undermining my own analogy here, but I think, in the software world, engineers and crafstmen can be one in the same.

      I think there is definately an engineering component to programming. Engineering is essentially applied science. So a software engineer is a programmer who is extremely knowledgable of the science of programming, yet has considerable knowledge of the practical side. Personally Id put a programmer who designs CPU micro-code in the engineering side. As I would probably put many embedded programmers and OS programmers. They may be craftsmen as well, but i suspect that on the whole there are broadly identifiable skills and training that are not generally shared with other types of programmers.

      But of course all of these definitions and concepts are misleading. IMO this is one of those situations where Kuhn got it right. Software engineers are those people doing things that software engineers consider to be software engineering. Coputer scientists are thos pople doing things that other computer scientists consider to be computer science. And the rest of us, well we are as the OP says, probably best described as crafts people. Not quite engineers, not quite artisans, not quite scientists, but a happy amalgamation of the whole lot.


        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi

Re: (OT) Programming as a craft
by pg (Canon) on Dec 16, 2003 at 04:50 UTC

    Compare with 20 years ago, programming nowadays requires much less "craft", and to the general public of this computing world, now it is actually discouraged for one to make programs "craft".

    Don't misunderstand me, obviously coding still requires skills (great skills), but the level of trickiness is largely reduced now. 20 years ago, you play a piece of trick, people may worship you; but if you play tricks now, lots of people can give you a big lesson on software engineering..., as we, including I, would rather have code that can be easily understood and maintained, not too much "craft".

    Coding with more wisdom, but less cleverness.

Re: (OT) Programming as a craft
by demerphq (Chancellor) on Dec 16, 2003 at 12:22 UTC

    This is a retake of the old "art vs science" debate. And I think you've hit the nail on the head. Its both. And thats what "craft" implies. The fusion of both. Not all programmers are craftspeople. Not all programmers are scientists or scientific about what they do. Not all programmers are artistic at all. So theres room for all three. But if you are a general purpose programmer who takes pride in your skills, and your trade, and your products, then I'd call you a craftsperson.


      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi

Re: (OT) Programming as a craft
by crouchingpenguin (Priest) on Dec 16, 2003 at 13:29 UTC
Re: (OT) Programming as a craft
by bsb (Priest) on Dec 18, 2003 at 08:03 UTC
    Hackers and Painters by Paul Graham

    What hackers and painters have in common is that they're both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They're not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

Re: (OT) Programming as a craft
by xenchu (Friar) on Dec 16, 2003 at 21:21 UTC

    I don't believe that there is any danger of programming as a profession vanishing any time soon. Here are my two main reasons for thinking so.

    First, I don't believe that the 'automation' you refer to will arrive as quickly as you think. Now, granted, people are always coming up with better and faster ways of perfroming programming tasks. Does anyone remember carrying around big boxes full of cards to be fed into a card-reader to enter your program into the machine? Long gone and good riddance. Through programming someone mated a tv(sic) with the proper software to replace that process. But that was a mechanical process and (fairly) easy to 'automate'. And even that process is still expanding and improving. I think it will be a very long time before you can hand a machine even the simplest specification which the machine can read and know what you want.

    Secondly, programming is one of those fields which is constantly expanding into new areas of human endeavor. Think of the parts of human life that computers touch now in some form that they were not thought of even ten years ago. How many of us drive a car that has a computer in it? How many of us carry a computer around with one hand? And how long will it be before we talk to our sleeve to order our computer to do something?

    The point I am clumsily trying to make is that computer uses are constantly expanding. Creating the software and programs they use requires human judgement. And human judgement, feeble as it can be, is not going to be replaced any time soon.


    The Needs of the World and my Talents run parallel to infinity.
      Creating the software and programs they use requires human judgement. And human judgement, feeble as it can be, is not going to be replaced any time soon.

      For now, I agree with you. But I believe that in the future (and very possibly the very near future) this will no longer be a true statement.

      Consider the workers in the automobile factories. How long ago was it that they felt that their skills at constructing cars could never be replaced by machines? And how many of those people have been replaced by now with robots?

Re: (OT) Programming as a craft
by hardburn (Abbot) on Dec 16, 2003 at 17:21 UTC

    . . . Software Engineer and Computer Programmer are essentially synonyms, even if the former perhaps sounds more important to a certain portion of the population.

    What you express here is the underappreciated difference between "connotation" and "denotation". Denotation is the raw dictionary definition. Connotation is what people think of when they hear a certain word (note that connotations often vary between cultures). Words that are synonyms have the same denotation. However, no two words ever have preciely the same connotation.

    As of now, I'd say that "Software Engineer" and "Programer" fill the same position within most companies, so they do have the same denotation. As you pointed out, the conotations are very different, and this may lead to a split between the two in the future.

    (Side point: the underappreciation for the denotation/conotation difference has led to the abuse of the Thesaurus by encouraging people to use egregious words that they don't fully understand (which, I've heard, is exactly the opposite effect the creator of the Thesaurus was trying to make). The Thesaurus says they're synonyms, so people just fill it in. MS Word's worst feature, IMHO, is that you need only right-click on a word to bring up a list of synonyms. At least before people need to page through a book before they rammed a bullet through their foot.)

    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

Re: (OT) Programming as a craft
by Sandy (Curate) on Dec 17, 2003 at 19:45 UTC
    All of this discussion has me a bit confused.

    Since I did not pursue a career in 'computer science' or 'computer engineering', I am uncertain as to what people mean when they say programmer vs. engineer.

    To that end, I will say 'programming', but I could mean 'software engineering' depending on what the definitions you apply to these words.

    Since I am a scientist, there have been many a discussions with fellow workers about the differences between scientific vs engineering practices, what kind of people choose which, does it affect the way they approach problems, etc. And yes, I do believe there is a difference.

    However, when it comes to writing software, designing software, designing systems, etc., I personally have not noticed a difference in approach/style based on one's academic background.

    aside... I tend to debug in a fashion that is totally alien to my fellow workers... they think I'm weird. Too bad. I'm good!

    When I argue/discuss 'best software practices' with my managers, I often insist that good programmers are artistic, and they typically love what they do. If you try to push the artistic nature into 'one method for everybody' you will lose the effectiveness of some, while possibly increasing the effectiviness of others. I'm curious, am I completely off the mark? Do you see yourselfs as artistic when you code?

    I think the way we code is personal, and is indicative of our personality and thought processes, as much as it is the necessity of the job requirements.

    To this end, I believe programming is a craft, mixed with an engineering approach (the guy who built my sun-deck had to know how to support it so it wouldn't fall down, as well as make it look nice), possibly a little bit of scientific thought processing.

    I also think that the variety of programming styles compliment each other, depending on the nature of the work required. For example, sometimes I need someone to tell me to stop insisting that I must know all that there is to know, and just write the d*** thing!. By the same token, sometimes I get to tell that other person that s/he wouldn't have made that mistake if they understood all that there was to know.

    I truly believe that the 'outside' world does not understand programming, or why we get such a kick out of it.

    So, if someone wants to call me a craftsman, I'll take it as a compliment, if they call me unskilled, I'm gonna kick them in the shins!

      I'm curious, am I completely off the mark? Do you see yourselfs as artistic when you code?

      Yes, absolutely. That's precisely the reason I consider myself a craftsman (if I may say so myself). As someone else said in an earlier post, crafts are something of a mixture between science and art. I think this is true, and what you say reinforces it in my mind.

      The point you bring up is interesting, though. I suppose the choice between being primarily a "craftsman" and an "engineer" is entirely personal. I guess it's obvious and true, but just something I hadn't really put any thought towards.

      I truly believe that the 'outside' world does not understand programming, or why we get such a kick out of it.

      I agree. This is something I had in mind while writing my original post, but I'm not sure it came across quite like I wanted. This is, I think, a common factor of most crafts -- people on the outside see a programmer, or a carpenter, or a mason, but do not necessarily think of all the differences between different programmers, carpenters, and masons. This is the thought that caused me to post in the first place.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://314940]
Approved by pfaut
Front-paged by BrowserUk
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (3)
As of 2022-12-06 18:24 GMT
Find Nodes?
    Voting Booth?

    No recent polls found