The author makes a great point and something I've been struggling with. We have so many great tools and with tech constantly improving it makes it hard to focus on a single topic area. Personally, I've gone through so many tutorials on so many different languages and frameworks (Obj-C, javascript, python, ruby, etc etc etc) but have never really focused on a specific stack. I think the most important for any new developer is to choose an area like web development or ios programming and focus on the fundamentals of programming. It's just like learning a foreign language, you're never going to be able to speak fluently until you do it everyday for months or years.
A Cautionary Tale of Learning to Code
51–60 of 135 posts
Re: A Cautionary Tale of Learning to Code
#52The problem is that crash-course developers are too satisfied with just making something work and most online tutorials are focused on language syntax. If you're learning to code, great for you... but I'd be scared to be part of your team, maintaining your code.
Yeah. There's a huge difference between learning "how to code", and how to actually design good software. Lots of a focus on the former, almost none on the latter.
Re: A Cautionary Tale of Learning to Code
#53Great article and observations. It's always good to see what this field looks like from a newbies' eyes.
If it only it were so simple as keeping a small tool set and a dev team committed to it. You can certainly build a business from scratch with a small toolset. But as the business adapts to customers, you always start to find things that customers want that the tools do not support. In initial dev, you don't necessarily care, but when you're live, it's better to implement than say 'no' to executive management and sales in most (not all) cases.
Once you modify the tools a bit to support the unique business, you're no longer able to keep new developers focused on a small toolset, because you've customized. New devs may not agree and may look for ways to work around the customizations. Soon, you have a unique codebase that is valuable- central- to the business, and your changes have crept in to the point that off-the-shelf devs and tools and upgrades don't work.
Now you're in maintenance mode. Code schools don't teach maintenance, but it is the lifeblood of the software business. Developers avoid maintenance jobs. They try to find new, greenfield work. That's why we end up with so many disposable business models, 3 year dev-to-acquisition cycles, and ridiculous amounts of abandoned code.
Maintenance is hard. Much harder than development. But it's much more important. Anyone can launch an app that builds a business. Not everyone can adapt and grow that business with code changes that require getting out of the dev comfort zone.
Code schools don't teach this because they don't want to expose aspiring coders who just want to get rich to the grimy dirty details of a real profession. But ask yourself this- would we have cars and highways if all we trained were new car designers (not mechanics or road builders)?
Re: A Cautionary Tale of Learning to Code
#54Earlier quoted context omitted.
Perhaps because you can learn to code without several years of intense schooling. The bar to entry is significantly lower.
You can learn to clean teeth without several years of intense schooling, you cannot learn peridontal surgery in that time, nor by "practice", in a reasonable amount of time or without losing a few patients. What is interesting to me is that we have gone from having computers go from giant obscure machines in room, leased by large corporations, to having them all over the place in your house. There is a gradation of e…
> And that last bit is something that computers have largely avoided by consistently disclaiming all warranties. When that changes, and programmers (or their employers) are held liable for the incidental or consequential damage caused by their bugs, you will see a much stricter code for hiring and employing people who write code that runs on other people computers.
My understanding is that life-critical systems have a pretty high bar today.
(Also, since we're on the topic - what do you think of having some level of Professional Association ala the Bar or the Professional Engineering association)
Re: A Cautionary Tale of Learning to Code
#55For the past year I've been learning to code in Python. My basic methodology was this; I had come up with an idea for a niche product - I reckoned at the time that something like this would sell. All I needed to do was to code it up - at the time I had been reading about Python and had tentatively prodded and poked it as I wanted to find out why a lot of my acquaintences were always scoffing at this language... "I fr…
Likely some people would be interested, but it seems fairly unlikely that a mass market would actually pay money for it.
Once you go from "all debian and ubuntu users" subset "those that use xrdp" subset "those that need to customize their configuration" subset "those that are willing to pay money", you probably don't have a lot of people left ;-)
http://www.amazon.com/gp/product/B004J4XGN6?btkr=1 - The Lean Startup is received wisdom on MVP. On the positive side, you've built a product and shipped. Now you can do it again, but with a product people actually will pay money for.
Re: A Cautionary Tale of Learning to Code
#56Earlier quoted context omitted.
Because one finds many self-taught developers out there who can outperform college-educated compsci majors day in and day out. Because one can read universally-acknowledged figures explaining how a large number of people with a software engineering degree can't code their way out of a paper bag or pass the most basic "fizz buzz test". (1) Because we can see non-genius 17-year-olds writing apps that are bought by top…
Software engineering is a relatively young field. However, to say we don't properly understand the fundamentals is absurd.
I agree. Sometimes we do take the reductionist approach, take the Apollo guidance software or seL4 as examples. However, when winging it gets you results that are almost as good in a fraction of the time, you can't be surprised at the prevailing method of software 'engineering'.
Re: A Cautionary Tale of Learning to Code
#57Earlier quoted context omitted.
You can learn to clean teeth without several years of intense schooling, you cannot learn peridontal surgery in that time, nor by "practice", in a reasonable amount of time or without losing a few patients. What is interesting to me is that we have gone from having computers go from giant obscure machines in room, leased by large corporations, to having them all over the place in your house. There is a gradation of e…
> And that last bit is something that computers have largely avoided by consistently disclaiming all warranties. When that changes, and programmers (or their employers) are held liable for the incidental or consequential damage caused by their bugs, you will see a much stricter code for hiring and employing people who write code that runs on other people computers. My understanding is that life-critical systems have…
> what do you think of having some level of Professional
> Association ala the Bar or the Professional Engineering
>association)
Re: A Cautionary Tale of Learning to Code
#58A Cautionary Tale of Learning to Fix Teeth. My own. How a reasonably balanced individual nearly went insane I was just a guy in a suit in an office with a vague healthcare idea. Then I decided to learn to fix teeth. I overheard some guy at a happy hour bragging about how easily he was able to automate his overbite by using a technique called "4 Handed Dentristry". I thought, "huh, 4 Handed Dentistry." I went home, go…
Because one finds many self-taught developers out there who can outperform college-educated compsci majors day in and day out. Because one can read universally-acknowledged figures explaining how a large number of people with a software engineering degree can't code their way out of a paper bag or pass the most basic "fizz buzz test". (1) Because we can see non-genius 17-year-olds writing apps that are bought by top…
Architecture, engineering, and the law are all well over 6,000 years old.
People have changed less (ed: more slowly) than you might think. Consider, people where applying makeup 6,000 years ago and there is some evidence the practice is ~100,000 years old.
Re: A Cautionary Tale of Learning to Code
#59For the past year I've been learning to code in Python. My basic methodology was this; I had come up with an idea for a niche product - I reckoned at the time that something like this would sell. All I needed to do was to code it up - at the time I had been reading about Python and had tentatively prodded and poked it as I wanted to find out why a lot of my acquaintences were always scoffing at this language... "I fr…
Likely some people would be interested, but it seems fairly unlikely that a mass market would actually pay money for it. Once you go from "all debian and ubuntu users" subset "those that use xrdp" subset "those that need to customize their configuration" subset "those that are willing to pay money", you probably don't have a lot of people left ;-) http://www.amazon.com/gp/product/B004J4XGN6?btkr=1 - The Lean Startup…
Indeed, and it's actually been a fantastic learning experience in itself.
And yes, I do have one or two other ideas that aren't as niche and more to do with real-world applications needed by many more people - something which I was intending to move on to after I'd completed this one.
Thanks for the link to that book. :)
Re: A Cautionary Tale of Learning to Code
#60A Cautionary Tale of Learning to Fix Teeth. My own. How a reasonably balanced individual nearly went insane I was just a guy in a suit in an office with a vague healthcare idea. Then I decided to learn to fix teeth. I overheard some guy at a happy hour bragging about how easily he was able to automate his overbite by using a technique called "4 Handed Dentristry". I thought, "huh, 4 Handed Dentistry." I went home, go…
Because one finds many self-taught developers out there who can outperform college-educated compsci majors day in and day out. Because one can read universally-acknowledged figures explaining how a large number of people with a software engineering degree can't code their way out of a paper bag or pass the most basic "fizz buzz test". (1) Because we can see non-genius 17-year-olds writing apps that are bought by top…
That is engineering, software projects with today's tools and techniques are not. This will happen some day in software. We are not there yet, by far.
Sure we are, at least pretty close.
Commercial avionics software developed to DO-178B standards calls for reams of requirements, verification tests, compliance to process, internal quality reviews, external audits, and sign-off by FAA representatives.
A one-line code change can take days to implement, and might not be released to "users" for months or years.
But the software is extremely robust.
If we wanted to engage in the same level of software engineering for all software, we could. But we don't want to. Developers don't want to, and users don't demand it. If an iPhone game crashes, who cares? If a productivity application crashes, you might have lost an hour's work, but it's probably not so annoying so as to warrant a couple orders of magnitude more cost associated with the software.
But if a software failure could kill people, well, that's different. It's worth spending a huge amount of time to make it perfect.
Avionics software can be so thoroughly tested because it is thoroughly designed up front. You know exactly what it's supposed to do. Much less-critical software is designed in a more ad hoc fashion; or there might not even be a design at all! How much software has been organically grown, starting with an idea and hacking on it until it seemed to work?
If you want to thoroughly test that, you have to go back and thoroughly state what it's supposed to do.
It's quite possible, but by and large it's not desired enough to make it worth actually doing. I'm not sure how this could change, or even if it should change. Instant bug fixes on web applications are cool, even though they come with the risk of having broken something else...