I have had a lot of opportunity to estimate a lot of projects, but one thing I still can't figure out is estimate education.
If a client wants to know "why is this going to take so long?" I can list the unknowns and third-party touch points, which are always things that make tasks take longer, but then they'll wonder why those are going to make it take longer. From there it's a challenge to communicate how unknowns are part of every project, how they are a good indicator of the risk of a task, and how there are some things you just won't know until you start work on a task in earnest.
Doesn't seem to matter how much detail I go into, it always comes back to "but I thought this would be easy."
The best I can come up with is to educate clients on what bad estimation looks like (Did they come right back with a fixed estimate for your type of project? Are they even asking questions?), hope they come back after getting different estimates with the exact red flags I warned them about, and then maintaining client trust by any means necessary so that when I say something is going to take a certain amount of time they know I'm not exaggerating.
I don't think it's quite the same. We live in an inbetween time - AI is not quite there yet.
AI struggles with knowledge from after its training date (so it can't help very well for anything relating to new versions of libraries) and often just generally gets things wrong or comes up with suboptimal answers. It's still only optimized to create answers that look correct, after all.
With these problems, someone on the team still needs to understand or be able to figure out what's going on. And dangit if it isn't getting hard to hire for that.
And the day that AI can actually replace the work of junior devs is just going to cause more complications for the software industry. Who will get the experience to become senior devs? Who will direct them? And even if those people also get replaced eventually, we will still probably have more awkward inbetween times with their own problems.
Can't say it's not convenient, but no use pretending the challenges don't exist.
When I went for a sleep study, I was wired awake for half the night, up in bed reading waiting for the study to be over. According to the study though, I was in sleep stage 2 the entire time I was sat up in bed reading.
Impossible for a teenager. This isn't like your everyday "kid makes a software startup" stories. He had to source all the machines, go through all the obscure documentation, understand how to test his yield, etc. He built his own photolithography machine ffs. I can't imagine the dedication required to go through this and believe in yourself every step of the way.
Helps to have some money too. I could just about afford to get some PCBs made for some RF work but ain't no way I was getting mum and dad to buy me my own electron microscope (or move house to have space)
I had the privilege of interacting with Bram a few times through Github and he was always fast, thoughtful, and pragmatic. I know others who would say the same thing. His software will always be one of my favorites of all time.
I always appreciated his charity work. Seeing that banner on vim was the first time I realized that I could apply my coding skills and turn around and give money to charity and have a real impact in the world.
What I tell people who get into software because they need a job is always that the industry also needs people with quality assurance and management skills.
Not because I want to offload people who are just looking for a quick buck onto those fields, but because I sometimes find that people with the right skills just take the long way around to transition into those roles. (I've even seen this happen once with a UX designer, but I think artistic people mostly know to try for those roles.)
People don't really consider the fact that it is a successful industry, but there are more roles in the industry than just developer. When the company I'm part of was a small startup, it was hard to find good people who were interested in taking on entry-level QA/scrum master positions.
I definitely agree about how it may appear to young programmers that they're casting magic spells.
I had the fortunate experience early on of building my own virtual CPU and RAM, then I learned assembly, then C, then algorithms, then OSes, then about Unix.
I'm not trying to toot my own horn, I've always been a little slow and struggled through this material. However, learning from the bottom up has granted me a lot of insight into how things work and an ability to learn pretty much anything software development related. SCIP has a different approach to "bottom-up" learning than I took but I think it still applies.
Maybe with all the tools out there not every programmer needs to learn from the bottom up, but someone needs to learn how everything works to build good tools, and if you can't learn that from MIT, I don't know where.
I disagree. The only reason modern computing can exist is because of layered abstraction. You don't need to understand the details of JPEG to write a computer game. You just cast the `jpeg.open()` spell.
Can you imagine if web developers needed to understand everything about how computers work. You must learn how a full adder works before you can use `+`. Oh and you'd better learn about resynchronization before you start using that SoC you bloody amateur!
I imagine everyone draws the "you should know the details about how this works" line juuust below the level that they know about.
> I imagine everyone draws the "you should know the details about how this works" line juuust below the level that they know about.
Yes this is usually what I see in tech spaces. I believe discovering _where_ that point is is largely moot and instead the focus should be on _having the ability_ to drop abstraction layers. Some day you’ll find a bug O(n!) and it may just be in a layer or two below.
I think the other reply to my post is on to something when they say there are many paths to mastery. I have just laid out one path. I don't know what the ideal general learning path is, but I know what worked for me. There is certainly a level where you gain enough knowledge to remove magical thinking entirely and you "learn how to learn", and there's no one way to reach that. I have not seen anyone reach that level by learning only specific abstractions, but I can only talk about my own experience.
I also don't think every programmer needs to follow this kind of path. All I'm saying is someone has to write "jpeg.open()" in the first place.
> All I'm saying is someone has to write "jpeg.open()" in the first place.
Of course but my point is that where do you stop? Someone had to design a multiplier. Someone had do invent a diode.
The point at which you say "I don't really care about the level of abstraction below this" is more or less arbitrary. Knowing more is better of course, but there isn't really any level that you have to know.
I would just expect MIT, of all places, to go quite low. I suppose everything has to come to an end, and MIT can't have the most intensive course forever. I just can't help but feel it's representative of what's happening everywhere.
Yeah you have a point. I would hope they have a more introductory module available first but I feel like SICP should be an advanced module for people specifically doing compsci. (I have no idea how American unis work; maybe it's already like that.)
I definitely remember when I did an engineering degree at Cambridge they had us doing assembly and typing decimal opcodes into a numberpad on an ancient microcontroller dev kit. I understood it but it sure was tedious and off-putting. And I say that as a typical HNer who has programmed forever and I even ended up doing CPU verification professionally. I imagine everyone else absolutely hated it.
Intuitively I find this view compelling, but I suppose it is somewhat arbitrary. After all, you can start in on integrated circuits and go many layers deeper from there to fundamental physics. And at the same time, we keep moving to higher and higher levels of abstraction with their own complexities to worry about and that's where most will end up working. Maybe the same curriculum doesn't quite make sense.
I think it's very hard to use an abstraction effectively if you don't know why it exists and you think it's magic.
I have seen programmers who don't understand, for instance, how key/value stores are implemented, come up with all kinds of improbable explanation about what might be happening to their code when it goes wrong, because they blame the data structure. Perhaps they even know the old idiom "don't blame your tools", but they've reached the end of their knowledge - something must be going wrong because of that magic data structure. Meanwhile, it's some kind of side effect they missed. Magical thinking. Sure, they learn eventually what to do when something goes wrong with that data structure, but they come right back to the same problem with everything they don't understand. Taking the magic out of anything, even if not always directly used, is extremely powerful.
I didn't say this before but I also have experience down to the level of designing and building circuits. I think the bottom-up model falls apart here because thinking about the physical properties of electronics is much, much harder than just dealing with idealized logic gates. You can learn it later, but its application is extremely specialized in my opinion.
I don't know, maybe I am biased because of my learning path, maybe students don't need to go as deep, but I can't help but feel that if I did it anyone can.
I have always claimed that the best way to understand regexes is to implement them yourself. This goes for hashmaps and other basic data structures as well. In general this advice has been very poorly received.
Going to the lower level (building the digital from the electronic) is to cross a much more hermetic abstraction boundary, perhaps this is why it's less broadly useful.
> building my own virtual CPU and RAM, then I learned...
Sounds like you know exactly where :-)
Being committed to a project or goal for a long time, taking your time with the foundational material, seems to be the most direct path to mastery in any field.
The problem is not the learning path doesn't exist, the problem is finding it and knowing if you should follow it. When you get started, you don't know what you don't know.
That's why I say I got lucky... I somehow found this learning path and decided to follow it without really knowing if it would be useful.
Yes, I think that dedicating yourself to any project for a long time will teach you a lot, but you can also end up with a lot of holes in your knowledge depending on the path that you take.
For instance, the most common mistake I see people make regarding learning programming is focusing too much on specific languages and frameworks and never learning anything that could be called fundamentals.
I suppose that's what this is really about. Fundamentals versus specifics.
The trick should be how to set things up so other people get lucky in the same way.
I could give you the same sequence of projects and goals I had as a curriculum, and it wouldn't work for you.
As an individual, if you follow this path, I think the answer is to continually be going back to fundamentals, because they will never stop being an inexhaustible font of inspiration for new ideas.
You bring up good points. In my opinion it's difficult to put together any kind of significant curriculum, and it's inevitable that it's not going to work for everyone and some people are going to struggle with it. However, there's probably some tipping point where the material just doesn't work for anyone.
I don't know how to account for that. I don't know what the curriculum should be, or how to make it more digestible. I just know that, as as person who hires other programmers and got a taste of both a software development program and my own self learning, I don't like what schools are putting out, and MIT's change in course material seems to be a drastic turn in that direction.
I am coming to the uncomfortable conclusion that organizational habits (hiring and promotion practices, VC preferences for engineering team structures, etc, etc) are more significant than what universities teach (or perhaps, ultimately, the former determine the latter) and we need a movement towards professionalization, and probably some kind of guild-like structure to gatekeep (that is, establish a competency floor) if there is to be any improvement over the status quo. Andrei Sorin's recent massive tome, though a bit of a rant, influenced my thinking quite a bit here.
That's an interesting idea, I'll give it a read. The big problem I see right off the bat is lack of available talent and hiring pressure, but I reserve my judgement.
I'm editorializing a bit, his formulation of the idea is a little different from mine, but enough time in the industry makes it hard not to conclude that something is eroding the professionalism of the field, and I think his ideas about what it is are probably, if wrong, at least wrong in a very interesting direction.
> I had the fortunate experience early on of building my own virtual CPU and RAM, then I learned assembly, then C, then algorithms, then OSes, then about Unix.
I suppose what's missing from that experience is the reality of programming "in the large", where modularizing code and creating well-defined interface boundaries becomes quite critical. The easiest step forward coming from C would be learning something like Rust - or, historically, C++. This is when the broad high-level patterns and approaches that SICP discusses at length in a theoretical way become practically useful.
I have been on teams that never review code and teams that always review code, and I can confidently say I never want to work on the former again. That was with a junior team, but your team is going to have new people, if not junior, at some point. People who are familiar with each other's code and have agreed on standards can review code pretty quick. I would rather have it and not need it than need it and not have it.
If a client wants to know "why is this going to take so long?" I can list the unknowns and third-party touch points, which are always things that make tasks take longer, but then they'll wonder why those are going to make it take longer. From there it's a challenge to communicate how unknowns are part of every project, how they are a good indicator of the risk of a task, and how there are some things you just won't know until you start work on a task in earnest.
Doesn't seem to matter how much detail I go into, it always comes back to "but I thought this would be easy."
The best I can come up with is to educate clients on what bad estimation looks like (Did they come right back with a fixed estimate for your type of project? Are they even asking questions?), hope they come back after getting different estimates with the exact red flags I warned them about, and then maintaining client trust by any means necessary so that when I say something is going to take a certain amount of time they know I'm not exaggerating.
reply