Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Spending thousand of hours in front of my computer, ergonomics became quickly a main issue.
For the monitor or the keyboard, technical solutions exist. But for the mouse, I never get used to the trackball and putting a little pillow under my wrist made me feel uncomfortable.
So I started to swap the hand that holds the mouse. It's great, one can rest while he other is working. At the beginning it was hard, but now I don't really see the difference unless I try to kick an ass at Quake III ;-)
Anyway, a lot of people would not be comfortable with this idea, do not have the time, and above all, can not afford the mental switch that comes with the use of the other hand. Indeed, using the other hand make you use the other side of you brain (logical <=> creative), making very hard to concentrate the first times.
I am happy about it but can understand that many people would not. Do you have a better idea ?
Take regular breaks from using the mouse, and learn keyboard shortcuts!
There is a tool called Workrave which will make you take a short break every few minutes, I use it and it seems to be helping.
Yeah I had that problem too for a while. The first thing I did was modify my chair so I had a flat area where I could put a mouse and rest my arm on the padded arm wrest. Now I have an L shaped desk, and can rest my whole arm on the desk ( from elbow to hand anyway ). I found that it makes a big difference over just wresting my wrist. I still use my modified chair to hold a flight stick for gaming though ;)
This is classic RSI, you need to change your mentality for the sake of your body.
Personally I do not see why people have trouble with switching to Logitech Trackman's your hand does not move, just your thumb.
To me traditional track balls fail as you have to have your hand hovering over them or your hand bent upwards. However with the trackman your hand is put in a natural curve so it feels comfortable. I used to play Americas Army using one and had no issues with speed.
I tried a vertical mouse but found it to be more uncomfortable because you lose the wrist support afforded by resting your hand on the mouse.
It was a waste of money for me, but your mileage may vary.
Thanks for the initiative to go back to hand switching. I learned it years back, and it took about two weeks to get accustomed. Since then, I can gladly use both hands with the mouse.
Interesting home work for sports oriented: learn to play badminton with both hands. :P
This kind of exercise is generally good for our brain. Stretching it one way makes it perform better in others, too.
IBM used to make keyboards with their famous track stick in the middle. Probably, Lenovo continued that product after they took over.
If you can get used to such a device, it is very useful, especially since there is then no need to take the hands off the keyboard while working.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have it in my course and i dont understand the practical use of learning it
This isn't the forum to be asking ultra-novice questions, or I apologize but overall "stupid" questions like that, but I'll give it a go to answer you. Hoping that understanding the "why" will fuel your compassion to learn what appears to be an unnecessary class and hopefully to one day prevent you from boning over your company's sysAdmin ultra hard.
Plain an simple "You need to know hardware to not program crap software" and I don't mean you need to know what GPU is recommended by Tom's Hardware, or that your machine has 8GB of ram and a sweet SSD.
You need to know endianess(https://en.wikipedia.org/wiki/Endianness) to program efficiently. You need to know core counts to run a self-managing, self-scaling nodejs clustered server, and what chip onboard codecs run best for a given configuration. You need to know that also to create a valid virtualbox machine or VMWare machine. You need to know the lowest possible denominator so that you know how your RAID Array is going to perform.
You need to know how many read/writes SSD's can manage before breaking down so you don't botch a company's entire data repository cause "You thought Samsung SSD's were good!"
You need to know about platter space so you can keep things running nicely, and trimming so your SSD on that old "Vista" machine they won't get rid of doesn't fill up with non trimmed data.
You need to go into Bob Joe Company, who's using WindowsXP and tell them where they can utilize their spend dollars the most efficient and safe way.
You need to know input/output, you need to understand the differences between VRAM and physical RAM, clock speeds, overclocking, latency, cycles, Hyper Threading, onboard/discrete hardware. You need to know why many things once existed to know why they are done the way they are today.
For example, when you have a horrendous update on your physical machine that blows everything up, you need to know that in a FUBAR situation you can jump CMOS and start over (that's a physical HARDWARE button that many lvl II's and III's often don't even have a clue about, guess where I learned it before ever being in IT? " Intro to computers - Hardware ")
"Unlearn" while you're in school and you'll find there's much you did not "learn" as you thought you did the first time around.
If you don't get pumped up over hardware.... software is not for you bro.
If you're not frequenting Tom's and the ][-][, or even worse if you don't know what those mean you're probably wasting your time. I'm not saying you can't be a software programmer, but you should at least read the article below and reconsider why you chose "programming" as a major.
(http://blog.codinghorror.com/please-dont-learn-to-code/)
That said I can tell you this.... I failed out of software in ITT-Tech but I never stopped attending, I changed majors to "Multimedia" which included some Adobe CS3, and also some JavaScript in web and finished in IT-Multimedia with honors and I STILL until a few years ago(about 3-4 years after graduating) only started to pick up some coding in my spare time. I found that I really enjoyed it, and you might to so I'm not discouraging you by any means. But read the above linked page and ask yourself if you're really meant to be happy as an IT worker in coding software. Maybe find something you're going to grasp to get your feet wet first, and take some low cost coding classes to get the idea of OOP like "CodeSchool.com"(40/mo but lots more content than) or "CodeCademy.com"(free, but not as structured or thorough as codeschool.com) You may find that you want to code, but it's going to take some time and practice to get readied up for true development.
I hope it helps man, I'd hate to see you make my job harder forcing yourself into a career you're not meant, or ready for. But I'd also genuinely like to see people be happier with more than a decent paycheck. :)
http://www.CodeSchool.com $40/mo
http://www.CodeCademy.com FREE - less content, slower to update
I m doing a research project on "Object detection using my a digital camera".
Some suggestion on how to build and program the Matlab code.
In particular, I have a picture of one object, say a screen of my laptop. Than I rotate the laptop and I shot a new picture. I would like to know the difference on the position of the screen. I think I can use the edge detection after a subtraction of the two images but... it is quite difficult for me to implement it.
Some suggestion on how to build and program the matlab code.
That largely depends on the goal you want to achieve. Can you be more specific? Are you streaming the frames or are you tracking offline?
In particular, i have a picture of one object, say a screen of my laptop. Than i rotate the laptop and i shot a new picture. I would like to know the difference on the position of the screen.
There are many ways to do this, and an extensive litterature on the subject. I don't believe anyone would write up the equivalent of a survey paper on the subject as an answer on StackOverflow. Why don't you get started with an object tracking survey paper and then ask a more precise question?
hi, I m doing a reasearch project on "Object detection using my a digital camera". [...] I think i can use the edge detection after a subtraction of the two images but...is quite difficult for me to implement it.
What is your question? Are you asking us if this is a good way to track objects? Are you asking us if this is a new approach and has never been done? Are you asking someone to implement it for you?
Object tracking is a hard problem. I doubt that technique would succeed in any but the most basic scenarios. However, if you look at a survey paper, you might be pointed to a paper that already implemented this an presents results. Finally, I think you should brush up your programming skills because most (successful) object tracking techniques are not trivial to implement. If you don't want to program it yourself, there are online services where you can hire people. StackOverflow is not one of those places.
EDIT: I could deduce that you're new to both programming (in MATLAB) and in object tracking, hence in my answer. Don't mis-understand me, I'm trying to help. Let me re-phrase my suggestions as list:
Your question is far too general. You will get a lot more help from the SO community if you ask more precise questions for two reasons: A) general question result in general answers; and B) the way you asked your question could easily be interpreted as "someone, please do my work for me" even if that's not what you think you're asking.
Get acquainted with the problem domain. To ask more precise questions, you must be close to your answer. For good knowledge on the "object detection and tracking", find a good survey paper. If you're starting off on a research project, people in your lab should be of help to point you to a good one.
Learn to program simple things first. All of the most proficient (effective and efficient) programmers I've ever met struggled with the bubble sort when they were introduced to sorting. None of them would have been able to program an object detection algorithm as a first assignment. Get yourself a good image processing book that has exercises in MATLAB, go through execises one by one. If you can't do them all, choose those that are relevant to what you're trying to accomplish.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What is your method of "mapping out" an idea before creating it?
Say I wanted to take on a big project, for example at the scale of a site like Facebook or MySpace. What planning/design steps should I take before I start the actual work?
For example, should I map everything out page by page (their functionalities, data, etc.)?
For a large project first think of a one-liner to description of your site (try to not use any buzzwords here). Next think of three design maxims (rules your design Should never conflict with). Then draw a few views and think up a few user cases (1 day) then work in code for 2 weeks (this will be a throw away prototype so just work as fast as you can forget about bugs and details, don't worry about code smells or design patterns, just make as much as you can), then revaluate all the steps above and throw away your two week prototype, and begin your project in a serious manner applying solid engineering and design. After a month has gone by evaluate your(team) moral and get feedback. If it all seems to be going ok, continue, you got a long ride ahead, otherwise just give up, do a postmortem, and start over with new goals.
I always start with the user interface design. I figure out what the user should be able to do and what controls I will give them to do it. Once I get that laid out in a way I like it, then I start with the code "wiring".
Make a list of all the features that site have.
Make a list of nice to have features.
Make a list of the weakness of the site.
Order that list and prioritize the items that will be built first.
Identify what will be possible to do and what is not.
Meet with your customer and present these results.
Usually I do a mindmap of
problem I am trying to solve,
translated into exact requirements,
then mapping that to user workflows.
The cross linking features of mindmapping softwares make it lot easy. Since mindmapping is 'kind of freeform', I end up concentrating on the 'task' rather than 'representation' (e.g which type of UML diagram should I use to represent this) ?
Once initial ideas are clear then I can work on project plan, spec/design documents using UML for more low level details. This approach usually works well for me.
To see if it works for you or not, you can use FreeMind (opensource mindmaping software, good but currently limited functionality). Then You can try Mindmanager or iMindmap for mindmaping. Both integrate well with other Office products.
Usually I start out by grabbing my scratchbook and just start writing down what I want as in terms of features, this should be quite detailed. And can be quite messy with every thing scrambled together, if so, when you're done make an 'official version' of you're ideas on paper (REAL pen and paper works best for this in my opinion).
Then I start making some scetches of how the pages would look like, what information it must contain and translate that to a global database design. Then work that global design to a more advanced level where all pages come together, with relations between tables and stuff.
After that I build up the most important pages on a code framework (I always make use of a framework, if you don't then forget the framework part), and by 'most important pages' I mean in for example a blog that would be the posts. After that build the not-so-important pages, in case of a blog that could be an archive of posts.
If you have that done, put the code together with a design, or do that while coding if you do not seperate code from HTML/CSS/JS.
Oh and yes, do NOT expand your first idea along the way. Just write that down and implement that afterwards. So if, in case of the blog again, you think half way you want Youtube tags in you're BB-code, write it down. Add that later, offcourse before you're initial site releases.
That's my workflow, at least a basic basic, basic description of it.
Start with "paper prototypes", i. e. take a pencil and sketch each page very roughly. This lets you start from the user perspective, which I think is a good idea.
You can then use the sketches for a first hallway usability test and later as the basis for "wireframes" you would give a web designer to work from.
If you've gone through the complete site once, you probably have a good idea of what the backend should be able to do. You can now use your page sketches and compile a list of the actions a user can trigger by clicking on things. This is the raw material for designing the server-side API that the frontend can call.
Using the calls that need to be served, you can design the backend: What functionalities group nicely, what data needs to be fetched, what do you need to store between page calls (== Session variables) etc.
In this process, I have fared quite well by postponing technology decisions (frameworks, protocols etc.) and even class structure etc., until I've gone through the whole thing once in terms of "what things should do what to what other things" (I guess there's a better term).
I think I would start with an open-source SNS solution that comes close to what you need and then figure out how to add use-specific plug-ins, modules, and themes that achieve your purposes. There are a lot of em out there. Building from scratch is going to take a lot more effort and planning. Most SNS functionality is not worth re-inventing. Focus on what will make your site unique and build upward toward that.
I'm a fairly visual person when it comes to designing software so I sketch out dataflows, class hierarchies, UI and flow charts on whiteboards and paper first.
Butcher paper and colored pens can be particularly fun to use as it's 3 feet wide and comes in 100 foot rolls. When you've got a design that's satisfying or sufficiently complete, tear it off the roll and pin to the wall. Update as necessary.
That technique has worked for some large refactors as well as new projects.
You could start with something very simple and then add features a little at a time. You may reach a point where you want to start over, but the groundwork you did will be beneficial. Or you can try to do the whole thing at once, in which case you'll need the advice already given in the other replies.
One more idea: Specify those features you are not going to include, and other restrictions. These are called constraints, and are as important as the rest of the plan, as it gives you boundaries so you know when you're done planning!
If you work for the same company as this person, start by getting everything in writing so you aren't the one to take the fall when the inevitable happens...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
Improve this question
I've never written functional specs, I prefer to jump into the code and design things as I go. So far its worked fine, but for a recent personal project I'm writing out some specs which describe all the features of the product, and how it should 'work' without going into details of how it will be implemented, and I'm finding it very valuable.
What are your thoughts, do you write specs or do you just start coding and plan as you go, and which practice is better?
If you're driving from your home to the nearest grocery store, you probably don't need a map. But...
If you're driving to a place you've never been before in another state, you probably do.
If you're driving around at random for the fun of driving, you probably don't need a map. But...
If you're trying to get somewhere in the most effective fashion (minimize distance, minimize time, make three specific stops along the way, etc.) you probably do.
If you're driving by yourself and can take as long as you like, stopping any time you see something interesting or to reconsider your destination or route, you may not need a map. But...
If you're driving as part of a convoy, and all need to make food and overnight lodging stops together, and need to arrive together, you probably do.
If you think I'm not talking about programming, you probably don't need a functional spec, story cards, narrative, CRCs, etc. But...
If you think I am, you might want to consider at least one of the above.
;-)
For someone who "jumps into the code" and "design[s] as they go", I would say writing anything including a functional spec is better than your current methods. A great deal of time and effort can be saved if you take the time to think it through and design it before you even start.
Requirements help define what you need to make.
Design helps define what you are planning on making.
User Documentation defines what you did make.
You'll find that most places will have some variation of these three documents. The functional spec can be lumped into the design document.
I'd recommend reading Rapid Development if you're not convinced. You truely can get work done faster if you take more time to plan and design.
Jumping "straight to code" for large software projects would almost surely lead to failure (as immediatley starting posing bricks to build a bridge would).
The guys at 37 Signals would say that is better to write a short document on paper than writing a complex spec. I'd say that this could be true for mocking up quickly new websites (where the design and the idea could lead better than a rigid schema), but not always acceptable in other real life situations.
Just think of the (legal, even) importance a spec document signed by your customer can have.
The morale probably is: be flexible, and plan with functional or technical specs as much as you need, according to your project's scenario.
For one-off hacks and small utilities, don't bother.
But if you're writing a serious, large application, and have demanding customers and has to run for a long time, it's a MUST. Read Joel's great articles on the subject - they're a good start.
I do it both ways, but I've learned something from Test Driven Development...
If you go into coding with a roadmap you will get to the end of the trip a helluva lot faster than you will if you just start walking down the road without having any idea of how it is going to fork in the middle.
You don't have to write down every detail of what every function is going to do, but define you basics so that way you know what you should get done to make everything work well together.
All that being said, I needed to write a series of exception handlers yesterday and I just dove right in without trying to architect it out at all. Maybe I should reread my own advice ;)
What a lot of people don't want to admit or realize is that software development is an engineering discipline. A lot can be learned as to how they approach things. Mapping out what your going to do in an application isn't necessarily vital on small projects as it is normally easier to quickly go back and fix your mistakes. You don't see how much time is wasted compared to writing down what the system is going to do first.
In reality in large projects its almost necessary to have road map of how the system works and what it does. Call it a Functional Spec if you will, but normally you have to have something that can show you why step b follows step a. We all think we can think it up on the fly (I am definitely guilty of this too), but in reality it causes us problems. Think back and ask yourself how many times you encountered something and said to yourself "Man I wish I would have thought of that earlier?" Or someone else see's what you've done, and showed you that you could have take 3 steps to accomplish a task where you took 10.
Putting it down on paper really forces you to think about what your going to do. Once it's on paper it's not a nebulous thought anymore and then you can look at it and evaluate if what you were thinking really makes sense. Changing a one page document is easier than changing 5000 lines of code.
If you are working in an XP (or similar) environment, you'll use stories to guide development along with lots of unit and hallway useability testing (I've drunk the Kool-Aid, I guess).
However, there is one area where a spec is absolutely required: when coordinating with an external team. I had a project with a large insurance company where we needed to have an agreement on certain program behaviors, some aspects of database design and a number of file layouts. Without the spec, I was wide open to a creative interpretation of what we had promised. These were good people - I trusted them and liked working with them. But still, without that spec it would have been a death march. With the spec, I could always point out where they had deviated from the agreed-to layout or where they were asking for additional custom work ($$!). If working with a semi-antagonistic relationship, the spec can save you from even worse: a lawsuit.
Oh yes, and I agree with Kieveli: "jumping right to code" is almost never a good idea.
I would say it totally "depends" on the type of problem. I tend to ask myself am I writing it for the sake of it or for the layers above you. I also had debated this and my personal experience says, you should since it keeps the project on track with the expectations (rather than going off course).
I like to decompose any non trivial problems loosely on paper first, rather than jumping in to code, for a number of reasons;
The stuff i write on paper doesn't have to compile or make any sense to a computer
I can work at arbitrary levels of abstraction on paper
I can add pictures and diagrams really easily
I can think through and debug a concept very quickly
If the problem I'm dealing with is likely to involve either a significant amount of time, or a number of other people, I'll write it up as an outline functional spec. If I'm being paid by someone else to develop the software, and there is any potential for ambiguity, I will add enough extra detail to remove this ambiguity. I also like to use this documentation as a starting point for developing automated test cases, once the software has been written.
Put another way, I write enough of a functional specification to properly understand the software I am writing myself, and to resolve any possibile ambiguities for anyone else involved.
I rarely feel the need for a functional spec. OTOH I always have the user responsible for the feature a phone call away, so I can always query them for functional requirements as I go.
To me a functional spec is more of a political tool than technical. I guess once you have a spec you can always blame the spec if you later discover problems with the implementation. But who to blame is really of no interest to me, the problem will still be there even if you find a scapegoat, better then to revisit the implementation and try to do it right.
It's virtually impossible to write a good spec, because you really don't know enough of either the problem or the tools or future changes in the environment to do it right.
Thus I think it's much more important to adapt an agile approach to development and dedicate enough resources and time to revisit and refactor as you go.
It's important not to write them: There's Nothing Functional about a Functional Spec
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We don't teach children calculus first. We first teach them arithmetic, then algebra, then geometry, the analytical geometry, then finally calculus.
Why then, do we teach our computer scientists frameworks and IDE first. Some curriculum do force students to learn computer science fundamentals, but the vast majority of graduates that I see could not compose a framework of their own to save their lives.
Where then is the next generation of tool builders?
How can we promote the understanding necessary to create frameworks and development environments?
This is of course a generality. Not all education is lacking, but it seems to be the majority and it brings down the quality of our profession as a whole.
I think the analogy is a bit off. A better analogy would be "We don't teach our kids to use calculators to add and subtract, why teach programmers to use an IDE to program?"
Get rid of HR departments that require X years experience in Y. The universities are just tailoring their course to the HR department's requirements.
I employ graduates who can code in something (I really don't care what language) and who can learn.
I see your point, although I think the math analogy doesn't quite fit. You have to know basic arithmetic to be able to get anything done in any other math discipline.
When I began programming frameworks were mostly unheard of. If you wanted a binary tree, by God, you went and wrote one. In C or Assembler. That was basically it, so to get anything done at all you had to know a lot.
Today, Frameworks and IDEs and designers make it possible for "noobs" to create actually pretty brilliant things without knowing the first thing about how to build a framework, or a compiler, or manage memory allocation.
The real issue is, what about all the dingbats that think they are awesome, great programmers because they used Frontpage or Access? Managers have a hard time telling the difference between that kind of programmer and one that really knows software development as a discipline.
So, specifically, why is it that way? Because everyone wants a job and nobody hires programmers that know how to build a binary tree. They want programmers that know .Net or J2EE, etc.
I would argue that there is probably enough work out there for 9 to 5 programmers who can start at the framework level and go up from there. The truly good ones - mostly your program as a career and/or program as a hobby - are going to get the knowledge they may have missed in college over time anyway. You can't force everyone to be a wonderful programmer no matter what curriculum you teach. Inquisitive students are going to learn about the fundamentals whether its taught to them in class or entirely on their own.
There are tool makers and tool breakers. And of course there are tools, but let's not go there.
If you have a good look at an automotive workshop, you will see a lot of funny little tools that you don't see on the shelves in hardware stores. Like the ones for pushing back brake caliper pistons. Or the clamps for compressing valve stems so you can get the collets out with one hand while talking to your mates about nailing the new secretary (instead of watching them fly across the room when the spring slips out from your screwdriver).
These were designed by mechanics. They're really effective, generally small and cheap, and totally incomprehensible until you seen them in action.
Most of the profound changes in automotive technology were bottom-up, but top-down is also needed. Individual mechanics can't make fundamental technology changes like the switch from cast iron to alloy heads. A new broom sweeps clean, an old broom knows the corners. You need both.
But I digress: the point is that the mechanics couldn't design these tools if they lacked fundamental skills and knowledge. My father built me an entire motorcycle from scrap iron when I was a kid. As an adult, because I lack his skills and knowledge and modes of thought, I can barely maintain the bike I bought from Honda, much less take to it with an oxy like Mr T in a creative frenzy.
With code, I am as my father was with steel. Donald Knuth is my constant companion, and when the wireless protocol for our GPS loggers needs to be implemented in .NET it's me they come to see. The widget monkeys wouldn't know where to start.
I think the problem is in fact the GUI paradigm in general.
Microsoft made using computers much easier, they popularized the Graphical User Interface. They brought this interface metaphor, (the desktop, the file) to the domain of programming as well and very effectively too with their Visual Basic tool.
But just as the GUI obscures what happens "under the hood" so does the IDE obscure the manipulation of bits and bytes. The question is, of course, risk to reward ratio - how much understanding do programmers lose in exchange for productivity?
A cursory look at "The Art of Computer Programming" might show why IDEs are useful; "The ultimate packing density is achieved when we have 1-bit items, because we can cram 64 of them into a single 64-bit word. Suppose, for example, that we want a table of all odd prime numbers less than 1024, so that we can easily decide the primality of a small integer. No problem; only eight 64-bit numbers are required:
p0 = 011101101101001100101101001001001100101100101001000101101101000000
p1 = . . ."
Programming is really hard, you can see how an IDE might help. :^)
Learning the abstraction is easier than learning the details when it comes to programming. It's harder to teach someone to hand-code assembler to print "Hello World" than it is to have them throw together a form with a button on it that shows a "Hello World" message when the button is clicked.
You didn't know how to build the engine of a car before learning to drive, did you? Because it's not necessary in order to drive. In the same vein, you don't need to learn how a linked list or binary tree works in order to maintain a list of names and search them.
There will always be those who want to get under the hood and learn the "why" of things, but I don't think it's required to get things done.
I always screen applications by asking difficult questions that they could only answer if they understood how something really works. I think it is a real shame colleges and universities are teaching people framework based development but not focusing on core software principles. I agree that what matters more than anything is someone who understands how programming works and has the drive to learn anything they can about it.
Most universities I know of have an introduction to computer programming course that teaches basic programming concepts. Unfortunately it is impossible to teach programming without actually writing code.
The problem is that some prefer to teach this course using some OO language such as JAVA or C# and so the students must use Visual Studio (or the Java equivalent).
It is very hard to explain the basic concepts when the IDE forces you to work in a certain way.
I think that the first language students learn should be functional language such as C. This way you have less layers of abstraction between them and the basic CS concepts.
Agree with cfeduke.
I looked at the work for the same CS courses I did from 2 years previously, and they were way harder. 5 years previously, way way harder.
The CS bar is being lowered more and more, presumably because there are more and more jobs that don't require any working knowledge of any of the complicated CS subjects. There are huge numbers of jobs for people to just cut code.
Since traditionaly people who wanted to be programmers did CS courses as coding has gotten easier this is still the case.
What really needs to happen is for CS to not be a requirement for professional software development. Instead there needs to be another curriculam that focuses more on getting people out the door and cutting code.
This would leave CS to be that course for you next generation of tool builder.