The Apprentice

  • djackson 22568 (9/9/2011)


    IceDread (9/9/2011)


    Ben Moorhouse (9/9/2011)


    I have to disagree with those saying that degrees and training outside of the workplace are good things.

    Whilst I've only worked with a limited number of developers, it's easy to spot those who had done degrees simply because they thought about things and structured things in the same way.

    Whilst this is sometimes seen as a good thing, in most cases I've found that they struggle to solve problems as a group because none of them could REALLY think outside of that degree shaped box.

    I'm biased though - Whilst I did an IT based AVCE at school, it was extremely simple and I went straight into work and taught myself everything I know about coding and the various database platforms available to me.

    My brother however, did a CS degree at university, but would call me for advice simply because he didn't have the experience to know what to do.

    When thinking about who I would like to work with, I'd choose achievements and experience over a degree any day.

    If you can choose between someone who has a degree and 10 years experience or someone who has 10-14 years experience, would yous till make the same choice?

    Behavior undefined!

    You can't answer this. It depends on the person. There are those with degrees (education, politics, and most liberal arts) who can't think their way past the drivel shoved into their minds. There are others (mostly science instead of arts degrees) who can. There are a large number of exceptions in both groups.

    I remember my discrete math class having a few education majors in it. Their argument was "we are just going to teach, why do we need to learn logic?"

    Really? Explains why so many teachers/professors are so ignorant of reality.

    I will take a non-degreed person who can show the ability to think, and the experience required, over someone who has a BS, MBA or other degree but who can't think. Usually though, having a degree shows you can think, again excepting certain useless ones.

    Maybe it's different in your country compared to Sweden but here most people in IT has a degree of some sort. Problem solving is an important part of the education. Having finished an education puts the stamp on you showing your at least this smart alá 125 in iq or something like that and it proves you can commit. Those with an engineer or civil degree are usually better than those with a software degree, the software degree is easier to achieve. I maintain that tech is not the important part you learn at university and it's also not the important part to learn, all thou helpful. I studied for instance most work at the uni in c, c++, java and a little t-sql. The language themselves was not the important part to learn, it was the concepts and problem solving and understanding. Today I work mostly with c# and sql. I actually did my final in c# without having studied it before, it was easy to learn.

    I maintain that a degree is good because you both learn and it proves who you are. From what I have seen, those without a degree gets lower salary, so that's another reason. However, you could of course be good without a degree but I believe it's less common.

  • Hey Steve, are you saying that my gebneration had no serious developers?

    From my point of view, it would be moe accurate to say that most senior developers didn't got to college to study CS. If they went to college, they went to college to study something else, and then maybe after they had their degree studied CS for their research degree.

    Back at the end of the 60s I was teaching computing (and doing other things appropriate to a member of teh CS department) at UEA; but that teaching was for postgraduate scientists and engineers to needed to know how to use a computer to help them do calculations needed for their phyics or chemistry or hydrodynamics research. The CS department was staffed by people with no CS degrees - it delivered supervision of research students resulting in people with good CS doctorates, taught applied computing to people who cared about the apps not the computing, did bits and pieces to help unioversity admin and/or other departments, and of course all members of staff were ddoing their own reseach (mine was on information storage and retrieval; . But we didn't teach acomputer science course for a first degree - The department head, Pete Stocker, reckoned there wasn't yet enough computer science that could be taught to undergraduates to make a decent degree course, and he didn't want to end up awarding degrees in Lisp or Fortran programming or anything equally unsuitable to justify awarding a degree.

    A few years later I was running a projects group employing a lot of people, mostly developers but also customer support people, and not one of them had a CS degree; I had people with degrees (sometimes doctorates) in maths, physics, history, classics,... you name it! Some UK universities were now awarding CS degrees, but not many. It was still true that most developers had never studies CS.

    So the first sentence in your editorial rang a very wrong note with me.

    Then you go on to say "became grounded in theory, struggled through assembler class, and understood the classic waterfall development technique. They could write bubble sorts and quick sorts, and could create and destroy pointers in thin air" - well, if US CS courses in the 70s like that I can only be glad that UK universties had no fallen into the same trap. You can't give anyone a grounding in theory by teach assembl;er (or C or Emacs, as suggested in the next paragraph) or bubblesort and quicksort (where are the other standard sort algorithms - there are hordes of them, where are the principles by which one decides what sort of sort is appropriate for a particular job if those are the only two sorts you know - you would be better off understanding the principles of various approaches to sorting but not knowing any particluar sort! You couldn't teach people programming if the languages you teach ignore pretty well everything that had been learnt about programming language design in the previous 20 years, all you could teach them was how to write fairly bad programs (all those pointers in thin air) in primtive languages. The victims of these courses were not being educated to degree level in computer science - they were being given low-value short-lived vocational training on whatever tools the universities could get their hands on cheapest. A CS graduate from a decent CS course can pick up new languages very quickly, can understand what the language is getting at and how its constructs can be used to do things effectively and accurately, and the function of computer languages in a CS course should be to give the student experience in as wide a variety as possible of programming techniques and the languages that support them, and if the only languages you teach are C and Assembler (or later Java and C++) you can't do that.

    So just in that one paragraph you've effectivel explained why at least two of the first 10 comments on your editorial are from people who rate CS degrees very lowly indeed as a qualification for a developer. The next paragraph shows that the colleges have carried on with more of the same - Java and ,Net, heaven help us! - Where is the data management? Where is the logic programming? Where are process description languages? Where are functional languages? Where is relational calculus? Where is lambda calculus? Where is Church's thesis? Where is recursive function Theory? The halting problem? Computational complexity, Data Flow complexity? Network, Hierarchical, and Relational data models and where are they applicable? Denotational semantics and Operational semantics of programming languages? Syntactic classification of languages? Modularity? Ergonomics? Capture and communication of requirements? Design for flexibility? Error management (prevention, containment, propagation, recovery, elimination) and system maintenance? Security models? Development and project management methodologies? Design methods, communication of design? Formal methods and associated languages and how they shape up? Type theory? Performance estimation and measurement, Sizing, Networks, basic information theory? They aren't teaching science (neither CS nor any other S) they are teaching trivial narrow technical skills.

    Then you go on to ask should we replace CS degrees by more vocational training. After you've shown that instead of real CS degree courses many colleges are already providing some vocational training! Actually, with those CS courses, maybe some decent vocational training would be a big improvement. But I think an even bigger improvement would be to have some real CS courses.

    Tom

  • Grant Fritchey (9/9/2011)


    I came into this career without a CS degree. Still don't have one. What I do have is 20 years of experience (and that mostly is 20 years of experience, not 1 year repeated 20 times). I've met people with masters and doctorates in CS that wouldn't trust to validate a backup. I've met self-taught developers that could write a WHILE loop. From what I can tell, it doesn't make a difference either way. It's down to the person, their abilities, their predilections, not the degree or lack thereof.

    One of the earlier posters asked if I had someone with a CS degree and 10 years of experience or just 10 years of experience, which would I hire (I'm pretty sure the assumed answer is the CS person wins out)... what does that experience look like? Because I'll tell you the truth, after more than 10 years involvement in interviewing and hiring people, I don't even look at their degree... ever. I don't care. I'll look at their experience and I consider military service a plus, but degree's... nope. And before you ask, certifications means they get asked more questions, not less.

    Like Grant I have no CS degree; I worked in IT for more than 40 years without one, and still do odd bits.

    When recruiting I looked at degrees if people had less than a few years experience (except at one company where it was company policy to require a degree for some positions) - and generally if we are talking of no experience at all and a first degree (BA or BS) I'd employ someone with a music or maths or whatever degree ahead of someone with a CS degree unless the degree came from somewhere I seriously respect. A doctorate in CS is someting I might consider useful - the title and summary of the thesis can be helpful in deciding whetherit is or not, and I might read the whole thesis.

    By the time someone has 3 years experience, it should be possible to tell more from achievements during those three years than from any bachelors degree. If it isn't possible to see any achievements in 3 years of experience, the person is in my opinion not employable as a developer. So really it's the achievements that count, not the number of years or the degrees or the certifications.

    I regard manufacturer certifications as almost useless - and the word "almost" is only there because, for example, MS may exclude a company from certain partnership programs (or statuses) if they don't have at least N MS certified people (N is generally either 1 or 2). This of course is one of the ways companies like MS sell their certification process.

    Tom

  • Tom.Thomson (9/10/2011)


    Hey Steve, are you saying that my gebneration had no serious developers?

    No offense intended, Tom. However I'd say that most of the people in your generation were more pioneers in software. I think that until Unix was established and the PCs started to appear in business, the landscape was still being developed.

    ...

    You can't give anyone a grounding in theory by teach assembler (or C or Emacs, as suggested in the next paragraph) or bubblesort and quicksort (where are the other standard sort algorithms - there are hordes of them, where are the principles by which one decides what sort of sort is appropriate for a particular job if those are the only two sorts you know - you would be better off understanding the principles of various approaches to sorting but not knowing any particular sort!

    I misspoke a bit. Early in my college career, we did lean the theories behind sorts, and other algorithms, and then had to implement them. We had almost zero attention paid to display and UI, and instead had to learn how to move information around.

    I do agree that the lack of good data theory is a problem as well, though I'm not sure when we introduce that.

    Then you go on to ask should we replace CS degrees by more vocational training. After you've shown that instead of real CS degree courses many colleges are already providing some vocational training! Actually, with those CS courses, maybe some decent vocational training would be a big improvement. But I think an even bigger improvement would be to have some real CS courses.

    I'd agree, and that's my point. We ought to move basic programming to vocational type training and move CS back to harder coursework. Drive people to be senior architect level developers if they invest the time in learning that stuff. Allow the current jack-of-all-trades, corporate level developers to be vocationally trained.

    Or self-taught for either group.

  • Tom.Thomson (9/10/2011)


    Then you go on to say "became grounded in theory, struggled through assembler class, and understood the classic waterfall development technique. They could write bubble sorts and quick sorts, and could create and destroy pointers in thin air" - well, if US CS courses in the 70s like that I can only be glad that UK universties had no fallen into the same trap. You can't give anyone a grounding in theory by teach assembl;er (or C or Emacs, as suggested in the next paragraph) or bubblesort and quicksort (where are the other standard sort algorithms - there are hordes of them, where are the principles by which one decides what sort of sort is appropriate for a particular job if those are the only two sorts you know - you would be better off understanding the principles of various approaches to sorting but not knowing any particluar sort! You couldn't teach people programming if the languages you teach ignore pretty well everything that had been learnt about programming language design in the previous 20 years, all you could teach them was how to write fairly bad programs (all those pointers in thin air) in primtive languages.

    Huh?

    First off, there may be hoardes of algorithms to sort, but I laugh when young developers try to tell me how Java can sort faster than the quick sort by using (insert some inane professors idea here). I have proven other developers wrong more times than I can count BECAUSE I took courses to understand the basics. I remember others failing those classes with the excuse that they are going to develop software they don't need to understand algorithms. Stroustrup and others built the best languages we have ever had because they understood the basics. One cannot write good software if one does not have at least a basic understanding of how the instructions are processed.

    "My app keeps crashing, I can't figure out why" is all too often caused by a so called "developer" not understanding what a thread or mutex is. Semaphore, what's that?

    Excuse my boldness, but the idea that one can program in Java and not worry about pointers is bullshit, and a large reason behind why software is so buggy today. I do not need the language to release memory for me, garbage collection is for sissies - I am one of those who CAN write my own memory manager in C or C++ when Windows doesn't provide what I require, all the while eliminating memory leaks and bugs! "Younguns" can't because they frequently don't have the education. A lot of them don't because a lot of instructors today are clueless as well.

    Now for the other side - there are an awful lot of smart people out there, including some very good instructors. I overcame the instructors who were incapable of speaking English, who couldn't explain the subject matter, and who had never worked for a living outside of teaching. The best instructors I had did in fact produce commercial software whether as a side job or something else, and THEY are the ones that helped me to understand what I needed to know.

    When I took my senior project class I was so far advanced over the instructor that he was incapable of understanding the code I wrote. I walked him through the well commented code produced by Visual Studio and he still didn't get it. There was no chance of explaining what my code did when he couldn't get basic Windows programming.

    Oh yeah, nobody at the college had wrote anything for Windows at that point! Why could I? Because I had stood on the shoulders of giants who went before me, learned some of what they knew, did my own research, took classes in assembler and computer operations, discrete math and linear algebra, calculus and geometry, trig and more.

    Sedgewick, Kernighan, Ritchie, Stroustrup - those guys are just a few of the people who gave us what we have today. There would be no Java, .Net, iPad, cell phones and a bunch of other technology without what they built for us to add on to.

    One last note, as so much of this post touched on nerves... My algorithm class was taught by a professor who the colege kept trying to fire because of the number of people he failed or gave low grades to. The student body wouldn't let him. Why? He taught us how to think! We discussed quick sort, bubble sort and "the other standard sort algorithms - there are hordes of them" as you say, as a FOUNDATION! I turned in a project where I had developed a previously unknown sorting algorithm, I was quite impressed with myself. He pointed out how that sort had been used for some time, just was one we hadn't had time to get to. Pretty cool that I discovered something even if someone else already had. Even cooler that he knew about it before reading more than a few lines! However, even though he was an exceptionally good instructor, his responsibility was to teach me the basics (foundation) and to then entice me to go further on my own. He could have done that with the quick sort alone. In fact, I seem to recall our first project was to find an algorithm that sorted faster than the quick sort! All the rest followed on that.

    Anyone can have their own opinion. But I don't see how anyone can argue that there is no need for a foundation, that learning the basics isn't a good idea. A well rounded education gives one a chance to succeed, a narrow education is a formula for failure.

    Dave

  • djackson 22568 (9/11/2011)


    First off, there may be hoardes of algorithms to sort, but I laugh when young developers try to tell me how Java can sort faster than the quick sort by using (insert some inane professors idea here).

    I hate to say it, but a basic counting sort can be coded in most languages* and is an O(n) sort; likewise other various bucket/bin/pigeonhole sorts, and has been known since at least the 50's (though I don't think it's really taught anymore; I don't know why, particularly with the larger amounts of RAM available now).

    I do agree that I see "Language X can ... [doesn't know what lies behind the scenes, or what the alternatives are]" as a sign of a less 'well rounded' and less flexible developer. I actually blame much of this on the "learn popular language X" mentality, combined with the "Just use the most popular libraries/API/Framework/... provided; they were written by people smarter than you, who know more, and the 'standard ways' always make better choices in every situation" mentality. Specific circumstances are best answered by specific choices, which may be common, and may not be.

    *At varying degrees of efficiency and capability, or lack thereof.

  • I think it is fairly well established (Spolsky etc) that you are either the type of person that gets programming or not. In general I believe I could look at someone's general computer usage and see if they could grok development - to me it is a transparent attitude or approach, an understanding of what is happening, that after some years experience I can now pick up on easily - I'll be honest I don't QUITE understand it, but I know it plain as the nose on my face.

    It's not related to your degree or otherwise. The degree can add a level of structure to thinking etc (my degree is in electronic engineering, my MDs in History) but in my experience it is an inherent quality that makes someone good at dev work.

  • I keep seeing the chest-pounding developers who claim if you don't know how to implement low-level structures in C (or equally low-level languages) that you're not a real developer/CS degree holder/etc.

    Folks, it's been *decades* since I worried about low-level stuff. I'm too freaking busy creating applications by my lonesome to bother with sorting and memory management. That's what *frameworks* are for. I assume that something like .Net (or the Java/C/C++ equvilents) are written by teams of specialists who *of course* are expert in the low-level things like memory management and efficient sorting and all the minutiae that go on behind the scenes. They can wring that last CPU cycle from an algorythm and have spent their careers doing exactly that.

    Thus I don't have to worry about it. Even if I wanted to there's no way my solution would be better than somebody who's been doing that one thing for years!

    So let the framework creators do their thing and I'll worry about the UI and user requirements and implementing high level security practices (like which users get to access which part of the application).

    There's a *reason* the majority of developers don't program bare metal anymore...

    :rolleyes:

  • djackson 22568 (9/11/2011)


    Huh?

    First off, there may be hoardes of algorithms to sort, but I laugh when young developers try to tell me how Java can sort faster than the quick sort by using (insert some inane professors idea here).

    I found your post quite difficult to understand, because you start off as if you disagree with what I say, produce the above irrelevance about Java and nonsense about sorting, but then go on to repeat pretty much what I said in the first place about the necessity for real science in CS degrees (albeit in different words and with a couple of minor historical errors).

    I do mean it when I say "nonsense about sorting" (although you appear to contradict it later, so it isn't really clear what you mean). There already you reinforce the point I was trying to make - because if you were taught that quicksort is always fastest and always the best sort to choose you were taught complete nonsense, not science. Robert Sedgewick pointed out that quicksort was optimal for "randomly ordered keys, abstract compare" and would I think be horrifed to see it claimed as optimal for other cases, see the slides for his talk "QuickSort is Optimal" at Knuthfest in 2002.

    You will be choosing a sort whose best case performance (measured in comparisons between a pair of keys, since comparison is usually the most complex component operation) is O(Nlog(N)), average/typical performace is also O(Nlog(N)), and worst case performance is O(N^2). Don't you think it might be a good idea to consider what the distribution of inputs is before choosing your sort, to make sure that you're notgoing to be bitten most of the time by the worst case? There are many common sort requirements where the input data is usually going to hit the QuickSort worst case, and then it is probably better to use a sort like merge sort whose worst case performance is O(Nlog(N)) and best case (which it hits on some of QuickSorts worst cases) is Order(N); or if you have enough random access storage for the size of your input, use a pigeon-hole sort or a counting sort (worst case performance O(N))? Or any other of the sorting algorithms that do better than QuickSort on the input you are likely to see? Of course if the mean of the first three values in the input is always a good pivot and the input is pretty much in random order and you don't have enough RAM for a pigeonhole sort QuickSort is a very good bet - but there are applications where the input to the sort is usually nearer sorted than random and QuickSort is a terrible choice.

    I have proven other developers wrong more times than I can count BECAUSE I took courses to understand the basics. I remember others failing those classes with the excuse that they are going to develop software they don't need to understand algorithms.

    Then if what Steve wrote is correct you were lucky - because the description his editorial gives of early CS courses in the USA indicates that they didn't cover the basics. There will of course have been exceptions, and maybe you caught one of those.

    Excuse my boldness, but the idea that one can program in Java and not worry about pointers is bullshit, and a large reason behind why software is so buggy today.

    I don't know anyone who thinks Java is a good language (I make I point of not knowing people who think that).

    Sedgewick, Kernighan, Ritchie, Stroustrup - those guys are just a few of the people who gave us what we have today. There would be no Java, .Net, iPad, cell phones and a bunch of other technology without what they built for us to add on to.

    Some of us would say rather that they are the people responsible for setting back the engineering discipline of programming by more than a decade. When C came out it displaced languages that were more difficult to compile because, for example, the compiler was expected to track aliasing so that it could enforce types safety. The C definition precluded alias tracking, so its use of pointers ensured that there was no reliable type system. The fact that anyone competent could knock up a compiler very quickly indeed caused it to displace languages that encouraged writing better programs and prevented some tyupes of prigramming idiocy. The result was a lot of bug-ridden software (if its use had been restricted to competent developers it would have done little or no harm, but of course it couldn't be so restricted; and it rapidly led to the phenomenon of developers who could only write in one language - something I'd never seen before I met C only programmers - who were, inevitably, not the competent ones).

    Anyone can have their own opinion. But I don't see how anyone can argue that there is no need for a foundation, that learning the basics isn't a good idea. A well rounded education gives one a chance to succeed, a narrow education is a formula for failure.

    I don't think we disagree on any of that.

    Tom

  • Steve Jones - SSC Editor (9/11/2011)


    Tom.Thomson (9/10/2011)


    Hey Steve, are you saying that my gebneration had no serious developers?

    No offense intended, Tom.

    None taken, Steve.

    I should have put a smiley in there to avoid you thinking it might have been.

    Tom

  • roger.plowman (9/12/2011)


    I keep seeing the chest-pounding developers who claim if you don't know how to implement low-level structures in C (or equally low-level languages) that you're not a real developer/CS degree holder/etc.

    Folks, it's been *decades* since I worried about low-level stuff. I'm too freaking busy creating applications by my lonesome to bother with sorting and memory management. That's what *frameworks* are for. I assume that something like .Net (or the Java/C/C++ equvilents) are written by teams of specialists who *of course* are expert in the low-level things like memory management and efficient sorting and all the minutiae that go on behind the scenes. They can wring that last CPU cycle from an algorythm and have spent their careers doing exactly that.

    Thus I don't have to worry about it. Even if I wanted to there's no way my solution would be better than somebody who's been doing that one thing for years!

    So let the framework creators do their thing and I'll worry about the UI and user requirements and implementing high level security practices (like which users get to access which part of the application).

    There's a *reason* the majority of developers don't program bare metal anymore...

    :rolleyes:

    And if nobody studies low level bare metal, who makes the frameworks of tomorrow? How does it hurt for all of us to understand it? We don't have to be able to create our own frameworks, but we should understand the theory behind it.

    Dave

  • Tom.Thomson (9/12/2011)


    djackson 22568 (9/11/2011)


    Huh?

    First off, there may be hoardes of algorithms to sort, but I laugh when young developers try to tell me how Java can sort faster than the quick sort by using (insert some inane professors idea here).

    I found your post quite difficult to understand

    Join the club, between your typos and grammatical errors I thought your post was suggesting and education isn't necessary. When I read your current post you make claims about what I said that simply aren't there. So I guess we can summarize that we both believe an education is a good idea.

    Quick sort has never been bested on pure speed on random data, however I did not say it is the best sort. Recursion has its own issues.

    As to nonsense - I can't apologize for what I passed on - I have actually had young developers try to tell me Java is faster than the quick sort. That speaks directly to their less than ideal education, not understanding the difference between an algorithm and a language.

    Dave

  • Jack Corbett (9/9/2011)


    One thing I'd add is a willingness/desire to continue to learn. In my relatively short-time in the industry I've seen plenty of people with 20+ years experience who are still working the same way they did 20+ years ago, when there are better/more elegant ways to accomplish the job.

    A willingness to learn is essential. Nobody without it will ever be any use as a developer, a dba, a system designer or a system architect if they don't possess that.

    But doing things the way they were done years ago is often right. Here's the approach I had to design problems in the late 60s

    1) Do I know a cheap and effective way of doing this that will meet all requirements? If no go to 3 else go to 2

    2) Are there any new ideas that might allow me to do it better or cheaper (answering this may involve some research)? If yes go to 3 else do it the old way

    3) Research known and proposed methods of handling this and similar problems, using available information resources (libraries, colleagues, technical journals, appropriate academic contacts, personal network, plus any new means that have become available since the bad old days: eg usenet and more recently, the WWW). If there are feasible approaches, evaluate them and eliminate any that evaluate as unacceptable. If more than one approach remains with acceptable costs and effectiveness, pick the most flexible one and do that, else go to 4

    4) Carry out and/or commission research into the problem with a view to discovering one or more viable approaches to it.

    I claim that even if I end up at step 4 I am still doing exactly what I would have done in four decades ago. And I also claim that there is no better nor more elegant way of doing it. And that still applies if I end up at step 2.

    Tom

  • djackson 22568 (9/12/2011)


    roger.plowman (9/12/2011)


    I keep seeing the chest-pounding developers who claim if you don't know how to implement low-level structures in C (or equally low-level languages) that you're not a real developer/CS degree holder/etc.

    Folks, it's been *decades* since I worried about low-level stuff. I'm too freaking busy creating applications by my lonesome to bother with sorting and memory management. That's what *frameworks* are for. I assume that something like .Net (or the Java/C/C++ equvilents) are written by teams of specialists who *of course* are expert in the low-level things like memory management and efficient sorting and all the minutiae that go on behind the scenes. They can wring that last CPU cycle from an algorythm and have spent their careers doing exactly that.

    Thus I don't have to worry about it. Even if I wanted to there's no way my solution would be better than somebody who's been doing that one thing for years!

    So let the framework creators do their thing and I'll worry about the UI and user requirements and implementing high level security practices (like which users get to access which part of the application).

    There's a *reason* the majority of developers don't program bare metal anymore...

    :rolleyes:

    And if nobody studies low level bare metal, who makes the frameworks of tomorrow? How does it hurt for all of us to understand it? We don't have to be able to create our own frameworks, but we should understand the theory behind it.

    Why? Unless you want to spend your career doing bare metal work? Most developers don't do that.

    I mean sure, cover it lightly but unless you're doing bare metal stuff or compilers or frameworks (and all these things now take teams of specialists and man-centuries of time) what is the point of delving *that* deeply?

    I create data-based applications. Should I then try to create my own database? I've actually *done* that, back in the day. 🙂 Do you know how long it takes to create a decent database, on par with SQL Server? Working by yourself? (laughing)

    I've created languages, compilers, frameworks, and other low level stuff. Nothing as sophisticated as you'll find now, of course, but I did do it. And you know what? Very little of that work is transferrable to what I do for a living. You know why? Because it's such low-level stuff *it's already a commodity*. I grab it off the shelf when I need it because I've got more important things to worry about.

    We have sorts. It's a checkbox on certain controls. Or you create an index on the database and write a query. We have compilers, we have languages, we have all kinds of data structures and UI elements and *operating systems* (speaking of bare metal).

    No need to reinvent the wheel. Using the inevitable car analogy does a car designer really need to know the intricacies of tire manufacturing? Or, when designing a new sedan, does he choose already existing tires? How about radios? Should he know how to design his own?

    My point isn't that *nobody* needs to know low-level stuff. It's that very few people need to know it, just as a linguist doesn't need to know cutting edge quantum physics to be effective.

  • roger.plowman (9/12/2011)


    I keep seeing the chest-pounding developers who claim if you don't know how to implement low-level structures in C (or equally low-level languages) that you're not a real developer/CS degree holder/etc.

    Folks, it's been *decades* since I worried about low-level stuff. I'm too freaking busy creating applications by my lonesome to bother with sorting and memory management. That's what *frameworks* are for.

    I disagree with you for this reason. It seems that without being able to understand low level structures, and have an appreciation for how socket networking operates, pointers work, low level functions like copy, etc., I think you lose perspective for how to program efficiently. It's just my opinion, but it seems that so many people I've met who graduated post-Java era ('92 or so), don't really think about what is happening in their frameworks, or try to be efficient in their use of the higher level functions.

    I don't believe we need to go to assembler to teach this, nor do I think that we should have people specialize this if they aren't low level programmers, but I do think that having to do a semester of C will ground people in the basics of programming and development. After that, if they move to higher level frameworks, that's fine, and hopefully then they learn to think about the functions they use, look for efficient working functions from the machine's perspective.

    I believe, and I may be wrong, but too often is seems people take the shortest method for the programmer to solve a problem, which often ends up being the longer method for the machine and becomes a bottleneck.

Viewing 15 posts - 76 through 90 (of 94 total)

You must be logged in to reply to this topic. Login to reply