There is certainly a place for "a little coding", as you put it. I used to work in an investment bank where traders would write their own Excel macros to perform duties it would've taken months for them to get IT to implement. But building most production-worthy software is not what "learning to code" is about. I guess I'm just trying to re-draw the line. Wouldn't want to stop anyone coding :-)
I kind of agree that there is a place for coding without becoming a developer, but what these recent "code schools" seem to be doing is trivialising software development itself. I certainly wouldn't want to stop anyone dabbling in coding, singing, learning a language, etc... but we wouldn't want to confuse that with taking any of those pursuits to a professional level, which is something else entirely, and not quite so "easy".
Wow... this hit Hacker News a second time!
I agree, perhaps we should be pushing more in the direction of engineering... at least for certain kinds of project / product. At startups, there's definitely a push in the opposite direction; towards Agile, less formality, etc. I suspect the two approaches to continue diverging.
Great comment, thanks. I agree on the difference between a Computer Science degree and a Software engineering degree. I have the former (Comp Sci), and that's the premise for my article. Many folks were never taught the strict definition of "engineering", and believe that's what they do as software devs. I know that's not what I do.
I'm simply going with the definition of true "engineering" taught to me as a software engineering major at university... and specifically that we don't do that formal definition of engineering. Of-course, other fields (mechanical, civil, etc) don't always follow all the formalities either, but there are ways of modelling that simply aren't available or aren't used by software engineers.
Yes, very true. And I am also comparing the startup flavour of software development (which I am involved in), rather than perhaps other flavours, such as finance, health care, etc.
Great point. Perhaps we'll be able to classify certain software practices as "engineering". Maybe even stricter forms of Agile. It would be great to head in the direction of it becoming engineering, rather than in the opposite direction.
That's a great point, and one of the reasons I was originally taught it isn't "engineering", strictly. I think we do a lot of what counts as engineering. But, you're right, we aren't formally certified as an engineer. Perhaps that (and the required rigour) will change.
I think "we're still figuring a lot out" sums it up for me. Perhaps it will become more rigorous over the next few decades. Perhaps we'll start to see more parallels with physical engineering.
As I'm commenting elsewhere, this is true... I didn't acknowledge that other physical engineering projects do indeed suffer from some of the main problems. What's missing in software engineering is the rigour and ability to reason so precisely about what's being built. I was originally taught (on a Software Engineering degree course) that it doesn't formally fit the definition of engineering, and I've not seen that change much, but I'd agree the definition is certainly up for grabs, and perhaps extension to include modern software practices, such as Agile.
Yep, you're right... I'm forgetting that physical engineering also suffers from some of the same problems. The thing that it adds though is a level of rigour, and ability to reason about the project, that we're still struggling with somewhat in the software world. Believe me, in 20 years since I was taught it's not strict "engineering", I've yet to see that change much, other than in safety-critical and cleanroom projects.
That's a good point. I guess that counts as the kind of "rigour" I was taught we're missing in software engineering. The definition could perhaps be extended. We do things differently, but maybe it's still engineering.
Having studied Software Engineering as a degree, I can assure you they teach software engineers the definition of "engineering", and stress that we are practicing something else or, at a stretch, an extension of engineering somewhat different from civil or mechanical. I realise that building projects probably suffer from many of the same weaknesses, but the degree of rigour, and ability to reason about the project, is definitely way higher than on software projects. I knew a few civil, mechanical and aeronautical engineers, and they tend to agree. That said, definitions like this can be hard to pin down!
Wow, so, Hacker News... didn't see that coming.
Thanks for the comments, good and bad, folks.
One thing I certainly agree with: Regular physical engineering isn't entirely free of many of the problems I mention with software engineering, but the ability to understand and plan more effectively does appear to be there. The complexity in physical engineering does seem to be a little more tangible. I know a few civil and mechanical engineers, so I'm not plucking this from my behind ;-)
In terms of the definition of engineering, and the argument that software engineering isn't "engineering", I was taught this way back at university (City Uni, London), in their Centre for Software Reliability, and it's something I've largely agreed with. However, I think it was mainly used as a warning mechanism for newbie software "engineers" like me, to let us know that what we do is significantly different from other forms of engineering, in terms of the rigour. Perhaps it still deserves the title, but I guess that's a longer discussion.
Fantastic point, thank-you! Yes, totally agree. I think we, as developers, often forget this. I think it's definitely about addressing things that people want to do / be.
I may just have to write this above my monitor for the next few weeks, to correct my focus!
Absolutely, I think you have to be bullish with whatever solution you first present to a potential market. That belief and (apparent) momentum are, in my opinion, part of what leads people to look harder at your offering.
Thanks, that's useful to hear! Agreed, I'm highlighting one potential "problem", but it's probably more complex and multidimensional than that: my aspirations for a general product, marketing experience, educating users about specific use cases.
Great to hear that you're gaining traction with runners and that you're resisting generalising your app. It must be tough, once you gain users, to decide on a roadmap.
lol - Thanks absolutely, spot-on!
I'm not ditching UbiquiList, but I plan to expose those few simple use cases more elegantly. I believe I can track back from this general solution, with marketing / education, and encourage folks to come on in.
I began like this, with some market research amongst potential users that I know directly. Worked closely with a few. But my problem was that I let myself lose track of this and, when I came back to them with my MVP, it had deviated (by virtue of me generalising it too much) from what they actually wanted to use.
So you're spot-on, and sticking with a few customers whilst building the MVP is probably a hugely important step.
"He basically suggests that you have to specialize in an industry vertical to get beyond the early adopters and into the masses"
I think that pretty-much sums it up!
To clarify, I modified the title of the post slightly. Now "This Tech Founder's Blind Spot", as I'm writing primarily about MY blind spot, theorising other tech founders might have (or have had) the same. I definitely know some who never struggled with this, and I quite expect to learn and progress beyond this.
Great comments, folks and good to hear everyone's experiences, both similar and conflicting.
Valid point, and I definitely see biting off more than I can chew as part of the problem. But I suspect architecting (in a lean way) for that bigger market, whilst hitting a smaller niche, may be the balance to be struck.