Author here - yep, that's exactly right. Didn't occur to me people would read it that way (whoops!) - I meant implementing ideas from scratch.
This was inspired by a lecture I gave to some entrepreneurs on Friday (I put a link to the slides in the post) - these folks are people with business / design backgrounds who are trying to figure out how to realize some idea they've been working on. It was part of a larger course they were in - my role was just to give them the CTO / technical co-founder's perspective on what to look for in building their early tech team, picking a technology stack, etc...
I ended up really having an intense discussion with them on "finding the developer to implement an idea from nothing" and tried to capture that in the blog post.
It was kind of funny because I thought at first that's what he was taking about, but then his message clicked and I agree. No developer should rely on one tool for the job; you have to be open-minded, try out new things, and explore new solutions. Taking this approach in the beginning is rather daunting, but definitely pays off in the long run when you have the ability to tackle problems from multiple angles.
Giant hunters. Not giant slayers, but the guys who have been around long enough that they have a pretty good idea of which shoulders to stand on if they want to reach something.
I must have been stuck in the HN bubble too long because I'm really surprised that there's non-technical entrepreneurs trying to start technical startups. How does that even work?
It may not be the stuff of unicorns, but there are quite a few niche markets where you might have someone who knows the problem space inside-and-out who may not be a coder. I've seen niche software that does everything from manage a farm to inserting those annoying mini-flyers into monthly mailed bills that you get from utility companies.
The article seems to be about building routine web and phone apps. There's no reason to build those "from scratch", and many reasons not to. The tools, libraries, and frameworks in that area are plentiful. Why re-invent the wheel?
A decade ago I wrote most of the software for a DARPA Grand Challenge autonomous vehicle. Now that was "from scratch". Almost every file was 100% new code. There were no libraries for that stuff back then. Unless you're doing something exotic like that, or have severe performance requirements, or are producing something for very high volume production, working "from scratch" seems pointless.
> Unless you're doing something exotic like that, or have severe performance requirements, or are producing something for very high volume production, working "from scratch" seems pointless.
Maybe. Platform limitations are a thing. And you started out your comment with the observation that not everything is a web-app.
Way (way!) back in the day, I had to implement SGI's new OpenGL spec on SunOS. Because it didn't exist, and we needed it for some internal semiconductor CAD programs. Which is to say: the CAD program developers had SGIs and the rest of semiconductor design had sun boxes.
You might be doing embedded, or robotics, or process control or field-monitoring or flight systems, or ... In many (most?) of those, you make a new directory, fire up vi on a main.c file and go from there. If you are lucky (and luck seems to improve w/ time, I will admit), you have enough headroom (space, performance) to do a lot of it in Python. Often not, though...
It's truly rare to find techies who are more excited to see the end result in the hands of productive and happy end users than they are about the technology used to build said solutions.
The trait is more a mindset, a philosophy of empathy than it is a technical skill of building software.
It's not that it is hard to build stuff from scratch, it's just that it is easier to use a tool to do it.
I worked on a project where we had to remove jQuery from the page, and it was a nightmare for all the developers that had never written vanilla JavaScript.
These days, I don't use jQuery or bootstrap, or lazy loading libraries because I can just add the functionality I need by myself.
Be cautious removing and/or avoiding jQuery. I was once using it for something very small in a project and I figure what the heck I can just use vanilla JS for it so I removed it. I then had several bugs because every browser has its quirks even with very basic JS. I mostly use jQuery not because I can't do it in vanilla JS, but just because thousands of hours have gone into making code that will work across different browsers and browser versions.
actually, nearly all developpers like to build things from scratch. The real difference is, as noted in the article, the one who will use the right tool for the job and the one who take "from scratch" literraly.
I see many people, doing 'from scratch' the same things for years just for the sake of it. Without realizing they are wasting time and introducing the same bug/mistake because they can't learn anything new. And when you present them framework, library or snippets, they are reluctent to learn or simply discover them.
I find the lack of curiosity and self questionning very disturbing, for a community that introduce themselves as rockstars and elite of society.
So a developper that can from scratch is for me, actually less interesting than a developper that know how to reinvent himself.
Generally, I agree with what you are saying. However, there is one example of someone speaking to the opposite view which I also agree with: Marcus Zarra: https://vimeo.com/97058344
I think the key there is that he is in somewhat of a niche: client-side iOS programming. By limiting the set of problems which he is reimplenting "from scratch" again and again, he has some hope of getting very efficient at the "from scratch" approach (he becomes an expert in that approach). I also think this approach is probably only realistic for very small slice of people (top-level talent whom are also lone-wolf contractors (no oversight, no collaboration)).
A little off-topic, but has anyone else found that a lot of Haskellers fit into that "pet technologists" category? I've worked with a number of them, and seen them sneak Haskell in, despite it not being the best choice for the project.
The really weird thing is that the couple of people I've encountered this problem with weren't very good at Haskell. A big ol' mess of code mostly in IO, scattered willy-nilly with a lot of code duplication (in Haskell of all languages!). No pipes, no lenses, unnecessarily partial functions, manual implementation of things the type system is supposed to do, just bad in every way. (Not saying you "have" to use pipes or lenses, but you ought to know what they are and choose not to use them, not have your choice forced by ignorance.)
And, uh, quite tetchy if I even hinted at the possibility there were better ways to write that stuff. These people also expect to be the only ones who know Haskell in the area and are, ahh, unprepared to be wrong.
For what it's worth, don't judge Haskell by these people anymore than you'd judge any other language by its worst adherents. It may not be The Answer To Everything (TM) but it is worth some study at some point by any developer interested in progressing their skills.
I asked myself the same question. What is the best choice depends on both stated goals, assumptions, and predictions, which means others might differ in their assessment of the right tool for the job. In this case, why was Haskell not the best choice for the project and do you think those that tried to introduce it would have agreed?
I am definitely 'from scratch' and looking for interesting projects, so if you need someone who fills this void please do get in touch. What motivates me: social value, technological boundaries, no bullshit hard and fast artificial business-technical lines in the business, and remote capable teams (meaningful contributions and communicative value over idle presence).
Well in a sense you're rarely building from scratch, in that you're using frameworks and libraries, but what he is talking about is someone who can build out your MVP. Its really pretty hard I'm in the process of building an MVP from "scratch", I'm using Meteor so not as gruesome as building a first product in bare metal C lol but one thing it takes is a manic level of dedication, forget about balance, the reason this is difficult to find is that most people expect this level of dedication for like $60-70/hour. If you want a coder to work that hard be prepared to be offering that person a CTO role, the work they're doing is so important to offer anything less than that is an insult, really. But if you're working this hard to own something then the amount of dedication it takes balances out the equation. Its not so much about problem solving as it is about dedication and tenacity, problem solving is a part of the tasks you do, sure but the central requirements are dogged tenacity and dedication in the face of adversity.
I'm in this exact position. Brought up in a startup with CTO role to build a complex piece of visual storitelling software.
A thing that miss from the list of competency is to fight thoot and nail feature creep.
We just released our mvp within a week of the estimate and it was hard to fight back all the 5 minutes types of addition that came to mind to everyone on the project.
A mvp is also an idea factory and over excitable folks will be gmtempted to add loads of stuff before user validation which kind of defeats the whole scope of it
What you should be able to do is look at the needs, break them down, and communicate (and eventually develop based off such) different approaches based in the business need.
Honestly, every new project rest api or below, I look at problems as a clean slate and then weigh other team members, long term plans, quickest path(as needed), Eric.
I would think most schooled software engineers would have the acumen for such.
[+] [-] huuu|10 years ago|reply
So even developers who can build things from scratch use frameworks when needed.
[+] [-] Aaronontheweb|10 years ago|reply
This was inspired by a lecture I gave to some entrepreneurs on Friday (I put a link to the slides in the post) - these folks are people with business / design backgrounds who are trying to figure out how to realize some idea they've been working on. It was part of a larger course they were in - my role was just to give them the CTO / technical co-founder's perspective on what to look for in building their early tech team, picking a technology stack, etc...
I ended up really having an intense discussion with them on "finding the developer to implement an idea from nothing" and tried to capture that in the blog post.
[+] [-] snake117|10 years ago|reply
[+] [-] zkhalique|10 years ago|reply
[+] [-] hyperion2010|10 years ago|reply
[+] [-] alextgordon|10 years ago|reply
[+] [-] ghostbrainalpha|10 years ago|reply
A great salesperson with a great idea, can recruit developers to implement the idea. It's rare, but I've seen it happen.
[+] [-] michaelpinto|10 years ago|reply
[+] [-] fit2rule|10 years ago|reply
https://en.wikipedia.org/wiki/Peter_Principle
I've learned to never work for someone who can't do your job, and that includes "Founders" and "startup people".
[+] [-] zkhalique|10 years ago|reply
[+] [-] cuillevel3|10 years ago|reply
[+] [-] Animats|10 years ago|reply
A decade ago I wrote most of the software for a DARPA Grand Challenge autonomous vehicle. Now that was "from scratch". Almost every file was 100% new code. There were no libraries for that stuff back then. Unless you're doing something exotic like that, or have severe performance requirements, or are producing something for very high volume production, working "from scratch" seems pointless.
[+] [-] ci5er|10 years ago|reply
Maybe. Platform limitations are a thing. And you started out your comment with the observation that not everything is a web-app.
Way (way!) back in the day, I had to implement SGI's new OpenGL spec on SunOS. Because it didn't exist, and we needed it for some internal semiconductor CAD programs. Which is to say: the CAD program developers had SGIs and the rest of semiconductor design had sun boxes.
You might be doing embedded, or robotics, or process control or field-monitoring or flight systems, or ... In many (most?) of those, you make a new directory, fire up vi on a main.c file and go from there. If you are lucky (and luck seems to improve w/ time, I will admit), you have enough headroom (space, performance) to do a lot of it in Python. Often not, though...
[+] [-] x5n1|10 years ago|reply
[+] [-] jheriko|10 years ago|reply
[+] [-] ak39|10 years ago|reply
It's truly rare to find techies who are more excited to see the end result in the hands of productive and happy end users than they are about the technology used to build said solutions.
The trait is more a mindset, a philosophy of empathy than it is a technical skill of building software.
[+] [-] ibudiallo|10 years ago|reply
I worked on a project where we had to remove jQuery from the page, and it was a nightmare for all the developers that had never written vanilla JavaScript.
These days, I don't use jQuery or bootstrap, or lazy loading libraries because I can just add the functionality I need by myself.
[+] [-] volker48|10 years ago|reply
[+] [-] h1fra|10 years ago|reply
I see many people, doing 'from scratch' the same things for years just for the sake of it. Without realizing they are wasting time and introducing the same bug/mistake because they can't learn anything new. And when you present them framework, library or snippets, they are reluctent to learn or simply discover them. I find the lack of curiosity and self questionning very disturbing, for a community that introduce themselves as rockstars and elite of society.
So a developper that can from scratch is for me, actually less interesting than a developper that know how to reinvent himself.
[+] [-] cellularmitosis|10 years ago|reply
I think the key there is that he is in somewhat of a niche: client-side iOS programming. By limiting the set of problems which he is reimplenting "from scratch" again and again, he has some hope of getting very efficient at the "from scratch" approach (he becomes an expert in that approach). I also think this approach is probably only realistic for very small slice of people (top-level talent whom are also lone-wolf contractors (no oversight, no collaboration)).
[+] [-] JshWright|10 years ago|reply
[+] [-] bjacks|10 years ago|reply
[+] [-] jerf|10 years ago|reply
And, uh, quite tetchy if I even hinted at the possibility there were better ways to write that stuff. These people also expect to be the only ones who know Haskell in the area and are, ahh, unprepared to be wrong.
For what it's worth, don't judge Haskell by these people anymore than you'd judge any other language by its worst adherents. It may not be The Answer To Everything (TM) but it is worth some study at some point by any developer interested in progressing their skills.
[+] [-] cwb|10 years ago|reply
[+] [-] contingencies|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] shams93|10 years ago|reply
[+] [-] LoSboccacc|10 years ago|reply
A thing that miss from the list of competency is to fight thoot and nail feature creep.
We just released our mvp within a week of the estimate and it was hard to fight back all the 5 minutes types of addition that came to mind to everyone on the project.
A mvp is also an idea factory and over excitable folks will be gmtempted to add loads of stuff before user validation which kind of defeats the whole scope of it
[+] [-] jmspring|10 years ago|reply
What you should be able to do is look at the needs, break them down, and communicate (and eventually develop based off such) different approaches based in the business need.
Honestly, every new project rest api or below, I look at problems as a clean slate and then weigh other team members, long term plans, quickest path(as needed), Eric.
I would think most schooled software engineers would have the acumen for such.