Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Coding, Ego and Attention

josebrowne.com

Post reply on HN
Print view View original

71–80 of 177 posts

Re: On Coding, Ego and Attention

#71

Post by thruflo22 »

oarabbus_ wrote: post #68
camgunz wrote: 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…

>We've been doing CRUD in our industry for decades. How can we not just say "this is how you do CRUD, we're done w/ that now" As an analyst, can you explain this bit? I keep hearing things like "that's not actually a software development job, just CRUD", "we're done with doing CRUD" etc. But it seems like between the application and the DBA all the CRUD is taken care of, wouldn't the developer just work on the applic…

Yeah, CRUD is a solved problem but you still have to do it.

Mapping state to the database is to web dev what applying paint to the canvas is to painting. It’s how you do it that counts. Saying otherwise is overly reductionist.

Frameworks exist that abstract CRUD away. But you end up sacrificing UX and / or flexibility.

Re: On Coding, Ego and Attention

#72

Post by skybrian »

camgunz wrote: 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…

Technology changes and user expectations change, and we need to adapt.

And it's not my area, but this seems to be true in construction as well? The building codes change, and available materials and components change, as do their relative prices. Maybe not as fast, but fast enough to make older books out of date.

Re: On Coding, Ego and Attention

#73

Post by slindz »

cybernabjo wrote: post #44
slindz wrote: post #20

Earlier quoted context omitted.

Counter point: I read that book this year. It definitely contributed towards resolving some unresolved childhood trauma, and I'm grateful for it, but it was no walk in the park.

Why is that a counter point?

The parent was sharing the book as a wonderful read and that you shouldn't be concerned about the title.

My counter point was that while I enjoyed the book's results, the read/process was the polar opposite of wonderful.

I felt my anecdata might be helpful to those who might pick up the book.

Re: On Coding, Ego and Attention

#74

Post by skybrian »

oarabbus_ wrote: post #68
camgunz wrote: 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…

>We've been doing CRUD in our industry for decades. How can we not just say "this is how you do CRUD, we're done w/ that now" As an analyst, can you explain this bit? I keep hearing things like "that's not actually a software development job, just CRUD", "we're done with doing CRUD" etc. But it seems like between the application and the DBA all the CRUD is taken care of, wouldn't the developer just work on the applic…

It's a reductive, dismissive way of thinking, like saying that everything is ones and zeros, or that we're just copying protobufs around.

The data that we manipulate has business meaning and there are consequences for the users that arise from how we model things. Consider the genre of articles like "Falsehoods Programmers Believe About Names" [1]. There is ridiculous complexity here, for those willing to see it, but some people get tired of it.

[1] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

Re: On Coding, Ego and Attention

#75

Post by thrwaway2892 »

camgunz wrote: 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…

Well written article, well written response. Sometimes us humans think that perceived improvement of conditions = improved conditions. This is false, but as a business guy calling the shots, my goal is to do the thing on paper in front of me by the deadline whatever the costs. Combine that with a developer's creativity and you get a new framework.

Re: On Coding, Ego and Attention

#76

Post by bradstewart »

oarabbus_ wrote: post #68
camgunz wrote: 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…

>We've been doing CRUD in our industry for decades. How can we not just say "this is how you do CRUD, we're done w/ that now" As an analyst, can you explain this bit? I keep hearing things like "that's not actually a software development job, just CRUD", "we're done with doing CRUD" etc. But it seems like between the application and the DBA all the CRUD is taken care of, wouldn't the developer just work on the applic…

Not OP, but my take: When people talk about "CRUD" in the way you describe, they're usually talking about one of two separate (but related) things.

The "it's not _actual_ development" framing is usually directed at applications which "only" allow users to perform basic actions on some data, basically UIs for manipulating a database. It is absolutely real development (in my view), but less sexy than AI/ML, big data, etc, etc.

You are correct that every application (with some sort of data persistence) needs CRUD. But how CRUD is implemented, for better or for worse, depends on the requirements of the application storing the data. For (most) relational databases, the low-level "how do I CRUD" is well defined: standard SQL queries. But if I use NoSQL, or flat files, or something; it changes.

The definition of CRUD also varies depending on the layer of abstraction within an application or the perspective of the user/developer. For example: from a DBA's perspective, CRUD is SQL queries. From a UI, CRUD might be a JSON API or GraphQL endpoint. From a server-side application, CRUD might be a specific ORM library.

Re: On Coding, Ego and Attention

#77

Post by ska »

thruflo22 wrote: post #71
oarabbus_ wrote: post #68

Earlier quoted context omitted.

>We've been doing CRUD in our industry for decades. How can we not just say "this is how you do CRUD, we're done w/ that now" As an analyst, can you explain this bit? I keep hearing things like "that's not actually a software development job, just CRUD", "we're done with doing CRUD" etc. But it seems like between the application and the DBA all the CRUD is taken care of, wouldn't the developer just work on the applic…

Yeah, CRUD is a solved problem but you still have to do it. Mapping state to the database is to web dev what applying paint to the canvas is to painting. It’s how you do it that counts. Saying otherwise is overly reductionist. Frameworks exist that abstract CRUD away. But you end up sacrificing UX and / or flexibility.

I suspect their point is more: if it's a solved problem, why do we keep making new ways to do it?

Re: On Coding, Ego and Attention

#78

Post by pydry »

oarabbus_ wrote: post #68
camgunz wrote: 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…

>We've been doing CRUD in our industry for decades. How can we not just say "this is how you do CRUD, we're done w/ that now" As an analyst, can you explain this bit? I keep hearing things like "that's not actually a software development job, just CRUD", "we're done with doing CRUD" etc. But it seems like between the application and the DBA all the CRUD is taken care of, wouldn't the developer just work on the applic…

CRUD is looked down upon because it's time consuming and repetitive when you do it with poorly designed tools and because it's the most common role.

I think it's mostly a class thing though. Test automation is similarly looked down upon even though it is often much harder to do right than regular coding.

There is a definite pecking order when it comes to programmer roles and it's not necessarily related to difficulty (although it correlates very strongly with pay).

Re: On Coding, Ego and Attention

#79

Post by pydry »

thruflo22 wrote: post #71
oarabbus_ wrote: post #68

Earlier quoted context omitted.

>We've been doing CRUD in our industry for decades. How can we not just say "this is how you do CRUD, we're done w/ that now" As an analyst, can you explain this bit? I keep hearing things like "that's not actually a software development job, just CRUD", "we're done with doing CRUD" etc. But it seems like between the application and the DBA all the CRUD is taken care of, wouldn't the developer just work on the applic…

Yeah, CRUD is a solved problem but you still have to do it. Mapping state to the database is to web dev what applying paint to the canvas is to painting. It’s how you do it that counts. Saying otherwise is overly reductionist. Frameworks exist that abstract CRUD away. But you end up sacrificing UX and / or flexibility.

Picking the right level and nature of abstraction for the problem at hand is something of an art. Too high and you'll straitjacket yourself. Too low and you'll spend most of your time maintaining ugly boilerplate.

One of the many reasons why CRUD is way harder than its reputation credits it with.

Re: On Coding, Ego and Attention

#80

Post by tantalor »

camgunz wrote: 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…

this is how you serialize: https://developers.google.com/protocol-buffers
Post reply on HN