Live data from Hacker News

On Coding, Ego and Attention

josebrowne.com

151–160 of 177 posts

Re: On Coding, Ego and Attention

#151
post #66

I get and agree with what the author is saying here, but I also think a big part of this is that in software engineering, so much of what we do is ephemeral. If you're a carpenter you'll know if you're good or not. You'll be able to do stuff like frame a house, replace a door, etc. And then when someone asks you how long it will take to frame a house, how much it will cost, what supplies/staff you need and so on, you…

The differences between carpentry and software engineering is that the problem space in carpentry is much smaller and pretty much static over time. It's rare for carpentry tools to get an order of magnitude more powerful over the course of a decade, and for 100 people to work on the same carpentry project.

The availability of inexpensive CNC machines and 3D printers are carpentry tools that have certainly bolstered productivity in the last 10 years. Probably not “order of magnitude more powerful”, whatever that means, but as one very successful carpenter friend put it: “I don’t even fuck around with table saws anymore”.

By contrast, I’m still writing code more or less the same way I was 10 years ago, with mostly the same tools, and have not seen “order of magnitude” level of anything contributing to my productivity.

Re: On Coding, Ego and Attention

#152

This post did not reach the conclusion I was expecting based on the title. For me, I think I've largely experienced the opposite relationship between ego and my programming productivity. Learning to program as a kid was probably one of the most exciting developments in my life up to that point, and I expect that's true for many people on this forum. I originally attributed this to programming's usefulness, and the ma…

This really resonated with me. Before getting into programming, I was a somewhat accomplished guitar player. By the time I was 20, I had played in a bunch of bands, recorded several albums, and gone on tour. As a result of these early successes, I developed a big ego about myself as a musician. I realize now that the main thing driving my musical career was that ego. I enjoyed playing, but getting better at my craft…

I feel that to be something that resonates with me. I started as self thought freelancer loved the symphony of creation and the end product you make. Then I got myself a job I had sucha enthusiasm and thirst for knowledge, I would go above and beyond. Then I burned out, the cycle has repeated couple of times now forcing me to take breaks in 7-8months. One thing I realised I still love creating stuff, but it's all too painful to do it for someone else. The major contributor to it is constantly changing of requirements, sometimes goals altogether scrapping of projects you put lot of brain power in and finally sometimes fighting against the tide. I have experienced people who are just there in the middle management adding unnecessary layer of red tape and doing anything to survive. I feel I'm done with it. I have picked some other stuff, currently searching for something other than a programming job, it's a risk because majority of my work has been programming, other than a failed startup. But I think I will take the risk of exploring.

Re: On Coding, Ego and Attention

#153
post #66

I get and agree with what the author is saying here, but I also think a big part of this is that in software engineering, so much of what we do is ephemeral. If you're a carpenter you'll know if you're good or not. You'll be able to do stuff like frame a house, replace a door, etc. And then when someone asks you how long it will take to frame a house, how much it will cost, what supplies/staff you need and so on, you…

The differences between carpentry and software engineering is that the problem space in carpentry is much smaller and pretty much static over time. It's rare for carpentry tools to get an order of magnitude more powerful over the course of a decade, and for 100 people to work on the same carpentry project.

> The differences between carpentry and software engineering is that the problem space in carpentry is much smaller and pretty much static over time.

Anyone is free to compare software development with any engineering field, which typically have to solve large problems.

Thus if you feel carpentry is not a good comparison them look into civil engineering.

And no, the key factor is not the 'power' of software tools. The key factor is stuff like processes and standardization.

Sometimes it feels like software developers struggle or even completely oppose adopting and establishing processes and standards of doing things. Hell, the role of software architect is still in this very day and age a source of controversy, as is documenting past and future work.

We're talking about a field that officially adopted winging it as a best practice, and devised a way to pull all stakeholders into its vortex of natural consequences as a way to dilute accountability. The field of software developme t managed to pull it off with such mastery that even the document where the approach is specified is not a hard set of rules but a vague "manifesto" that totally shields their proponents from any responsibility of its practice delivering poor results.

If an entire field struggles with the development and adoption of tried and true solutions to recurrent problems then it isn't a surprise that basic problems like gathering requirements and planning is something that is still the bane of a whole domain.

Re: On Coding, Ego and Attention

#154

Self-improvement piece once again. Why are people so obsessed with this? Imposter symdrom seems to be a thing I really dont get. It never really bothered me if i actually caused the bug when looking for the root cause- ok maybe sometimes you worry if you messed up just before the release but thats pretty much it. Maybe realizing that you dont need to be a great programmer to make a great piece of software helps.

Imposter syndrome for me is kept in check if I keep within my 'quota' of mistakes. It doesn't bother me if I am the author behind a bug (Normally every bug is an opportunity to understand the software we've built better), but if consecutive bugs come back to my work, then I notice it. And I notice it in others too, and then I want to see them putting effort into improving their skill, etc..

Quota.. is that something like a percentage of bugs you feel responsible for? That again would be comparing youself to others- not saying its a bad thing unless its bringing you down. Dont really know what im talking about here as i have never suffered from that. Insecurity yes, imposture sydrom no.

Re: On Coding, Ego and Attention

#155
post #57

Earlier quoted context omitted.

> I still sometimes panic when initially faced with a very difficult programming problem, but I can put those fears to rest much more easily by saying, "ok, I've solved hard problems before. I may not know how to solve this particular problem yet, but I feel confident that I will be able to figure it out just like I did in the past with difficult problems X, Y and Z." The following this just my experience, but it's a…

Would you mind sharing which course you took please? It sounds very interesting.

It sounds like Offensive Security's OSCP and OSCE

Re: On Coding, Ego and Attention

#156

Earlier quoted context omitted.

> They say the way to get ahead at Google is to build a new successful product. Is that the same thing we're doing? It's easier to get ahead by building a new Z framework than to become a core committer on X framework from 10 years ago? A Kurt Vonnegut quote comes to mind: "Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance."

I think the reality is that some people are actually just fine doing the maintenance - but they're unlikely to boost their career/paycheck by doing so comparable to what they'd have gotten from making a new thing instead. And that's an issue. I'd love to go back to old code with the benefit of deeper domain knowledge and greater understanding of my tools and be able to make products even better. However, it's hard to…

> some people are actually just fine doing the maintenance - but they're unlikely to boost their career/paycheck by doing so comparable to what they'd have gotten from making a new thing instead

Is that really the case? Forums like this look down on maintenance a lot. But I find that real world companies much less so.

Re: On Coding, Ego and Attention

#157

Earlier quoted context omitted.

The differences between carpentry and software engineering is that the problem space in carpentry is much smaller and pretty much static over time. It's rare for carpentry tools to get an order of magnitude more powerful over the course of a decade, and for 100 people to work on the same carpentry project.

> The differences between carpentry and software engineering is that the problem space in carpentry is much smaller and pretty much static over time. Anyone is free to compare software development with any engineering field, which typically have to solve large problems. Thus if you feel carpentry is not a good comparison them look into civil engineering. And no, the key factor is not the 'power' of software tools. Th…

Ok, let's take another angle on this. The fundamental difference between software and most other engineering domains is that software doesn't involve physical matter (at least directly). The standards and design patterns in civil engineering, mechanical engineering, etc are driven by physical constraints. Whether it be monetary cost for constituent parts, or time cost for delivery, or just the limits of physics in general. Many of these limits are non-existent in software. There is no physical weight to a software object. A poor 10 year can make a million copies of it as easily as a rich software company.

Now there is software that tightly follows specs and standards, and you typically find it in critical systems, such as medical and aerospace. But there are orders of magnitude more software projects than non software engineering projects because they require so little to instantiate. There is almost no barrier to entry with software, and no BOM, and no supply chain.

Perhaps it would help to only call a subset of software projects as "engineering" - that would solve the problem. Not all software needs to be engineered. I don't need to engineer a script that downloads some videos for me or my personal website. And that's not a bad thing.

Re: On Coding, Ego and Attention

#158

Earlier quoted context omitted.

The differences between carpentry and software engineering is that the problem space in carpentry is much smaller and pretty much static over time. It's rare for carpentry tools to get an order of magnitude more powerful over the course of a decade, and for 100 people to work on the same carpentry project.

> The differences between carpentry and software engineering is that the problem space in carpentry is much smaller and pretty much static over time. Anyone is free to compare software development with any engineering field, which typically have to solve large problems. Thus if you feel carpentry is not a good comparison them look into civil engineering. And no, the key factor is not the 'power' of software tools. Th…

People make the civil engineering comparison all the time, but is software development really that much less standardized?

What's standard in building a bridge? You have some physical constraints(length, what's the bridge crossing), material properties, environmental constraints(temperature, weather, wind, what soil are you building on), what kind of traffic. Then there are standard 'shapes'(though it's your choice of suspension or whatever). You then have a ton of standard tests that you run to check that the bridge is fit for purpose. But it's not like the bridge is built out of legos, and even if a lot of standard subcomponents are used the assembly will still end up being fairly unique due to every location being different.

Software does in fact have tons of standardization. No one thinks of processor arch when doing web dev. Or DB implementation. Or how you modify the dom(there are a handful of libraries to choose from, similar to a handful of bridge designs).

How do you make a CRUD app? You can do some arthouse project, or you can just use Rails or various Rails-like frameworks. They're all mostly equivalent.

How do you serialize data? JSON(before that XML, I guess). Yes, you can do something different, but you can also build an apartment building out of reclaimed wood.

The real uncertainty lies at the User Interface, which really isn't engineering driven, it's fashion and art and stylistic architecture. So yes, the way websites look tends to change and be fuzzy, but so do clothes and no one complains about that.

I think software people both overestimate the standardization of physical engineering and underestimate the complexity of physical engineers' decisions, presumably they're not just following a recipe.

TLDR: When software standardizes a tool or process it becomes invisible, an import and forget somewhere in the pipeline of tools we use. This makes it seem like there's a lot of churn. But the churn is a bit of froth on the top of really solid foundations. Yes we're always working in the churning part, but that's because the foundational part requires almost no interaction at all.

Re: On Coding, Ego and Attention

#159

Earlier quoted context omitted.

This is my way of thinking: 99.99999% of applications out there still will store their CRUD into a standard relational DB and run on standard operating system with standard protocols. Sure you can create a lot of fuss all around it, but I feel we create a lot of fuss because of ego, because we want to be perceived that we came up with new ways. The reason to not conform is ego. Software is perhaps the cheapest ego bo…

Good. The only people who come up with new ways are the people who have the ego to try, and the world is richer for it. I'm glad the world is filled with engineers who try and fail and learn instead of those who would rather not create a fuss.

I think developing new ways to do CRUD is great but as an industry we take it too far.

I worked at an agency that produced CRUD apps at a rate you wouldn't believe. Every task was correctly estimated to the nearest hour. Add xyz entity 2hrs, add xyz frontend widget 3hrs, change deployment pipeline 4hrs etc. This was possible because they picked a tech stack and stuck with it.

I've also worked at companies where doing the same task could be 2 or 3 days. A place where no task can be estimated smaller than 1 day. The reason being the infrastructure, deployment pipeline, tech stack etc is overcomplicated. Way too much overhead.

Unless you are building some massive scalable solution all you need for BE is Spring/Django/.Net and an SQL server with a single backend dev who knows his stuff. Frontend you might need to change frameworks more often but still you can go a solid 2-3 years building momentum before needing to switch.

Re: On Coding, Ego and Attention

#160
post #66

I get and agree with what the author is saying here, but I also think a big part of this is that in software engineering, so much of what we do is ephemeral. If you're a carpenter you'll know if you're good or not. You'll be able to do stuff like frame a house, replace a door, etc. And then when someone asks you how long it will take to frame a house, how much it will cost, what supplies/staff you need and so on, you…

>There's something in here that's specific to SWE. I don't know exactly what it is but, I think we should figure it out.

It's changing requirements. When you build a house, people don't come in 6 months later and ask you if you could make one small change by placing some jet engines on the walls so the house can fly somewhere else during the summer. It's just a small change, right?

The problem is that in code, it often is a small change. Or at least, it is possible to make one quick adjustment to satisfy this new use-case. But often, these small changes are also a hack which doesn't fit into the previous overall design and which would've been implemented in a completely different way had the requirement been designed for in the first place. Now, one of these "small changes" don't tend to kill the product, but years or even decades do. That's why refactoring exists in software engineering, but not really in home building. Well, in some sense it does exist by renovating. But nobody thinks it's a good idea to completely renovate a house 25 times around an architecture that just doesn't work anymore for what it's being used for.

If you build a piece of software for exactly one well specified use case and only use it for that, it'll probably run really well forever. But (almost) nobody does that.

Post reply on HN