HN Theater @HNTheaterMonth

Software is read orders of magnitude more often than it is written. Therefore, the most important thing is to optimise your code for clarity.

Software is an interative process. Sometimes it can take 5+ draft versions before you produce high quality code.

There a good talk on this topic: Writing Software by David Heinemeier Hansson [1]

If you're short on time, you can skip to the highlight here: [2]

1. https://youtu.be/9LfmrkyP81M

2. https://youtu.be/9LfmrkyP81M?t=2702

Half true, I guess? I'm definitely in the camp of the CRUD developers. I do accept that I don't do lower level work (even making plugins/affecting how the framework works) in my day to day job. And it's fine. Evidently these skills are worth paying for and create value (monetary or otherwise) in the world.

An interesting take on this and the wider topic of how to write software is DHH's keynote from 2014[0]. He states that he himself is more interested in the 'Information System' parts instead of the 'Computer Science' part. I think there's space for more specialized titles to differentiate these jobs/skillsets.

0: https://youtu.be/9LfmrkyP81M

> This brought me back to the time my SO tried to explain an 84 year old lady she was assisting what is it that I do for a living. The consensus was that I'm a writer.

Maybe relevant talk from DHH coming to the same conclusion: https://youtu.be/9LfmrkyP81M

listen this talk by DHH you might get an idea

https://www.youtube.com/watch?v=9LfmrkyP81M&app=desktop

⬐ codesternews

Thanks!

⬐ aledalgrande

I had missed that video, it's great!

disagree, here is a great talk about how Software is more about French Poetry than Physics https://www.youtube.com/watch?v=9LfmrkyP81M

I really like this[1] talk from DHH on the subject, where he talks about the misconception of many programmers that we are doing science rather than something creative. While laced with hyperbolic statements it is at the very least thought provoking on some of the things that we do as developers.

1: https://www.youtube.com/watch?v=9LfmrkyP81M

I don't really see how this would be much more different from language to language. The being 'sick of' part, not so much the specific irritations. Every languages has its issues and from all the languages I have tried I have found Ruby to be the most pleasant to work with, but I am sure this is different from person to person.

One of the struggles that the writer seems to have is that programming applications is not science, but he seems to think it is. DHH has a great keynote on this phenomenon: "Writing Software by David Heinemeier Hansson"

https://www.youtube.com/watch?v=9LfmrkyP81M

As mentioned in the comments of the article you will run into issues with any programming language. One of the tricks is to not hold on so tightly to 'rules'. Like (take from the article) 'break functionality into lots of small objects'. This is horrible advice if applied to all situations. You should only do this when it makes sense. I see so many programmers breaking up everything in useless classes and methods/functions/whatever just because someone wrote a blog post about doing so. This just makes complicated code look simple at a glance, but when you want to find out what the code really does you have to jump up and down through files looking at what each function does, you have to open split screens between abstract classes that have some dedicated piece of code in a class that had to exist in order to satisfy the 'break things up' rule, etc.

Long story short: just relax, write code (in whatever language you like, for whatever reason), go home and enjoy your family, friends and hobbies.

⬐ cooervo

Yes! this so much. I remember a coworker who had to do an Interface or Abstract class for everything in Typescript. Only because typescript provides those features doesn't mean they should be used everywhere.

⬐ adamnemecek

saying that all languages have issues is definitely painting things with a broad brush. Why would I want to use an unmantanable slow language when I can use a fast maintainable language.

⬐ bsmithers

If you haven't discovered issues with your language of choice then you haven't used it enough

⬐ adamnemecek

This statement is a platitude. A: "Kim Jong-un is bad". B: "If you haven't discovered issues with your government then you haven't lived there long enough".

⬐ lloeki

Saying that all languages have some sort of idiomatic issues therefore there's no point complaining about language X is a fallacy that attempts to completely sidestep the issue at hand. You have to admit that although they may be Turing complete, all such languages are not pragmatically equivalent and some have significant pain points, possibly more impactful than others, otherwise we'd all code in INTERCAL and be all the merrier

⬐ macintux

I once wrote (by hand, over 3 or 4 pages) a program to add (I think, been >20 years) two integers using a Turing machine. I can definitely attest that not all languages are equivalent.

⬐ goatlover

So, why would one want to use the negatives from language X, when one could be using the positives from language Y!

⬐ mosselman

I find Ruby to be a very maintainable language. I use Ruby with Ruby on Rails which is a great framework to create web applications and the like. I would not use Ruby if I were in the system programming space as it is too slow and not strict enough. Every purpose can have a different language that is great for it, but don't forget that every programmer also has a language that is good for him. I, for example, will never work with PHP again because I find it ugly and I don't get happy working with it. Rust looks great though, when I find a purpose for it I might give it a go.

Ruby's slowness is often mentioned, but Ruby is quick enough for many situations. I am very productive in Ruby and servers are cheaper than developers so for many purposes it works out just fine. I have tried Phoenix (Elixir) and I found it too verbose and complex to work with. I am sure though that others love it, so to each his own.

⬐ raverbashing

> so many programmers breaking up everything in useless classes and methods/functions/whatever just because someone wrote a blog post about doing so. This just makes complicated code look simple at a glance

Thank you

I've seen people create classes containing only a string or a list/array of other (existing) objects, it's not even funny anymore.

⬐ mosselman

This is one of the biggest reasons for code becoming unmaintainable. Many people got mad at DHH for speaking ill of TDD, but he is not alone in pointing fingers at blindly restructuring code for the sake of (unit) testing as mentioned in the article.

I get why people would like to pretend that everything is made up of beautiful uncomplicated small pieces, but that is not how life works. At some point you have to understand your tax returns, mortgage contracts and communications with incoherent external APIs. Making me jump to section 4.1.2 and from there to section 7.2 in order to understand the parties mentioned under 1.1a are subject to the rules set out in Appendix A section 42.1 does not make the contract easier to understand. So why would code that feels like a legal document be easier to understand?

⬐ discreteevent

That's a really good example of the problems of indirection. I'll use it in future if that's ok. The thing that drives me mad about the promoters of decoupling is that they rarely talk about the downsides. The truth is that every time you decouple something there is a cost in complexity. One individual step to decouple something may seem small but the cumulative effect of many indirections in code can make it extremely difficult to navigate and understand. So when people decouple something they should understand this and make sure that the benefit outweighs the cost (which of course it does in some cases). The benefit of being able to test your code at a micro level rarely outweighs the cost.

⬐ mosselman

Thank you, yes please do. You nicely explained what I feel about this 'advice' when it is formulated compulsively like in the article. You made me think 'yes, exactly that' with regards to some people who seem to ignore the downsides of decoupling. Thank you for that, I'll refer to your comment in the future. Nice to come together like that.

⬐ DougBTX

> I've seen people create classes containing only a string

That can be a good way to improve type-checking in code that would otherwise pass around bare strings. It reduces the chances that e.g. a plain text string is confused with an HTML string.

If your language supports it, an opaque type alias would be more explicit:

https://flow.org/en/docs/types/opaque-types/

⬐ raverbashing

Yes, if the auxiliary class either checks or transforms the string in some way I agree

But that's in specific cases, not all cases

⬐ lmm

> I don't really see how this would be much more different from language to language. The being 'sick of' part, not so much the specific irritations. Every languages has its issues and from all the languages I have tried I have found Ruby to be the most pleasant to work with, but I am sure this is different from person to person.

And yet I never see people getting sick of functional programming after a few years. People either try it and dislike it immediately, or they switch and don't go back.

There really are better and worse languages, better and worse ways to write software.

⬐ StreamBright

True, however some languages have much less 'sick part' than others. It is just unfortunate that we humans tend to pick up the worse of everything. There is some hope though. In recent years there are many projects trying to provide a better programming experience and safer, faster results. Rust, ReasonML for example.

⬐ mosselman

I have yet to find a better programming experience than Ruby myself, but Rust looks fine for systems programming, etc. I don't understand however why people invest so much effort in Javascript. The amount of tooling around it just baffles me, but again, to each his own.

⬐ always_good

Seems kind of silly to compare client-side Javascript to languages that have no client-side solution.

⬐ mosselman

That might be more of a chicken-egg situation. One might argue that you could take even a hundredth of the effort that has been put into Javascript and put it towards an alternative and you'd come a long way.

Also, I am not against Javascript at all. I just don't understand the role it has been given on the back-end. There are better languages and on the other hand I don't agree with the amount of engineering that goes into front-end applications that are built in things like React. It seems silly to me to rebuild standard functionality of your browser in a framework in order to gain some interactivity that was already there to begin with through plain-old-javascript. Rather than invest all that time and effort into React, Redux, Redux-sagas, Ember, Vue, etc, etc, etc (there are a whole bunch of etc) people would have spent their time a lot more productively if they'd help out with making web components happen properly.

⬐ mercer

Ha, I can understand how you're baffled. As a primarily-front-end dev working with JS most of the time, I'd say the reason why it's worth it is that there's currently just no other language that runs in the front-end, or that is as ubiquitous a scripting language.

Much as my dislike of JS grows as I venture further into other programming ecosystems, I still love the ability to muck about with any web page I come across. I love being able to use the Chrome/Firefox devtools for debugging, and haven't found anything quite as nice outside of the browser. I love being able to package a bunch of js and a minimal html file, and just dump it anywhere that provides basic hosting.

It only barely offsets the many problems I have with JS, but because my day-job is mostly front-end, I need to deal with these problems anyways.

But man I'm looking forward to a situation where I could use <preferred language> as a drop-in replacement for javascript.

⬐ mosselman

I really like Javascript, I just don't like it when you use it in React applications and the like. It feels a lot like overengineering.

Want to muck around with websites with JS: https://bookmarkify.it/ (Disclaimer: shameless self-promotion on my part)

I think DHH sums TDD up best in this talk (which is absolutely fantastic btw): https://youtu.be/9LfmrkyP81M?t=24m

Many people might have already seen it, but I thought it'd make sense to mention DHH's talk at RailsConf either way.

In his talk, he is coining the term "software writer", which goes one step further and motivates a style of programming which prioritizes clarity of code over alleged technical superiority. Very opinionated, but recommended nonetheless: https://www.youtube.com/watch?v=9LfmrkyP81M

I don't want to misrepresent him, so I'll just point you to these links:

- http://signalvnoise.com/posts/3112-how-basecamp-next-got-to-...

- http://rubyrogues.com/056-rr-david-heinemeier-hansson/

- https://www.youtube.com/watch?v=9LfmrkyP81M