Hacker News Reader

Comment by olau | Hacker News Reader

The pattern seems familiar, take a succesful, self-propelled creative inventor, typically an engineer kind of person, put that person in a group where they need to submit to ideas of others, and things eventually go wrong.

It's not that unusual to see a founder get excluded even if that person was arguably the primary driver, the deteriorating relations don't allow the situation to continue and the alternative is blowing up the organization.

View on HN

This is one reason you should always just execute - never ask for permission. Have conviction - think your objective through - plan - cross your t's and dot your i's - and then just execute and show your results to everyone in your mgmt chain.

...to the degree that you can do that without getting fired.

It's always easier to ask for forgiveness than permission. Trying to convince a bureaucracy of anything is futile.

It's personality dependent. As in your actions have to align with your personality - https://en.wikipedia.org/wiki/Revised_NEO_Personality_Invent...

Some people can. Some people cant. There are no general rules that work for everyone.

like you can do that on a quantum computer machine. not everyone works on software

This just as easily applies to artists, its definitely not inherent to engineering.

In a way, engineers are a type of artist.

Yes, but management wants them to be assembly-line workers. A lot of organizational tension in tech companies can be traced back to botched attempts to force-fit artistic pegs into assembly-line holes.

Honestly, this is probably a big part of the reason I've really come to dislike things like Scrum and what Agile looks like now. My experience has been that these methodologies tend to treat devs as fungible cogs which fits very much with the idea of engineers/developers as assembly line workers.

Exactly this. Management wants every part of the production process to be easily replaceable, including the people. This is why management loves, e.g., Java. Java gives you a lot of the benefits of Lisp (GC, objects, exceptions) but without any of the features that facilitate writing beautiful elegant code. So Java code is ugly and festooned with boilerplate and using it is an incredibly painful experience (for a Lisp programmer). But if I'm a manager and I have a Java programmer working for me and one day I don't like the cut of his jib, I can fire him and instantly replace him with another Java programmer, because they are a dime a dozen and one is as good as another. As a manager, that one feature dominates all the cruft and the horror, because I don't have to deal with the cruft, I hire you to deal with it for me. And your replacability gives me power over you. So you type boilerplate while I play golf.

It would be a pretty good deal if I enjoyed golf as much as I enjoy writing Lisp code.

I'd always had the impression that this was the case, but when I started to program in Erlang after several years of Java it became clear to me how true this is. Java has been adding features that improve expressiveness, and from the perspective of a strictly Java programmer they are great. From the outside though, it feels like these new features still take way more work than should be necessary.

I appreciate what Java was meant to be (a way to drag C/C++ programmers closer to Lisp) and I would say that's a goal that has been achieved. I just wish it were easier to go the rest of the way.

Indeed, a power struggle. Management's natural responsibility is relationships to other humans, which makes them much harder to replace compared to a cog that performs a technical task, no matter how much skill that task requires.

How's the state of Lisp in production these days?

My one-man company uses a bespoke e-commerce system written in Lisp. It uses Stripe and Easypost on the back end and gives me a completely seamless fulfillment process that lets me ship anywhere in the world with essentially zero effort. I also consult for a major chip developer to help them maintain an internal design tool written in Common Lisp which they consider to be a major source of their competitive advantage. So it's not widely used, but where it is used it's a big win.

Sounds like lisp is good for a team of size 1, but are there any larger teams using lisp successfully?

I've heard theories that lisp teams don't scale well because the language is so customisable that team members have trouble reading each other's code.

That depends on what counts as a team. I use a lot of other people's code in my own projects. So although the people who wrote much of the code that I use didn't work for me, it's not exactly a solo effort either.

But yes, managing Lispers can be a challenge. That's one of the reasons Java is used so much more.

Hell I have trouble reading my own code. Dense, arcane, not descriptive of what's going on. FWIW

I love my code. Whether it's 6 months old or 20 years, I can readily understand it, and prefer it other people's code by a wide margin.

Erratum: It's too late to edit the comment, but what I was trying to say is that my code doesn't change because I don't learn. Alas, my wording somehow doesn't convey that at all.

Credits to the clairvoyance of JoeAltmeier for the kind correction!

Sorry didn't mean to be catty. Just that, our 20-year old code for most people seems naïve and clumsy.

Must not be learning? My code changes because I learn and change.

Someone with no actual experience in a team environment using Lisp just made that up, wrote it up into a glib article and that turned into a famous meme that gets trotted out about semi-monthly on HN.

What do you think of Stripe's docs? As an Elixir dev I'm somewhat dismayed at their trend towards assuming everyone is using one of their blessed handful of languages.

I mean, it's great that they've made a few official integration libraries, but if all the docs assume you're using one of them then the docs leave out crucial information about how to work with their systems for everyone else.

I suspect the information is all there somewhere but at least since SCA, it's buried. At least for me, the dev experience using Stripe has deteriorated quite a bit in the past 2 years.

Stripe's documentation is excellent. All you really need is a REST API.

There's definitely more to it than that. I wrote a very lengthy comment about my experience working through their payment intents docs with basic REST requests and hit quite a few errors due to requirements not mentioned either here or any linked page: https://stripe.com/docs/payments/accept-a-payment

It's worthy of a whole blog post, though, so I'll share it that way.

What can I say? I had no problems. But maybe you were trying to do something more complicated than I was.

Ok, here's the short version:

My experience going through the payment intents was that sending POSTs exactly as described was an immediate error for not sending a version in the request header. Nowhere in the doc was this requirement mentioned: https://stripe.com/docs/payments/accept-a-payment

The problem is step 1: "Use our official libraries for access to the Stripe API from your application"

Similarly the link on this page regarding webhooks leads to another page with similarly insufficient docs: https://stripe.com/docs/payments/handling-payment-events#bui...

If you're not using their library, there's no info about how to parse the webhook signatures and verify them. There isn't on this page either: https://stripe.com/docs/api/webhook_endpoints/

It ended up taking me half an hour to find a page that actually explained (with no examples) how to actually do it.

"Use the official library (and we have no plans to support more languages)" is not excellent documentation. TBH, it was one of the more frustrating experiences I've had with anyone's API docs in the past 2 years.

Again, what can I say? I wrote my stripe code over three years ago so I don't recall many of the details. All I know is that I don't recall having any trouble with it.

FWIW, I finally found what I needed after finding some of their older docs that predate SCA.

I think the problem lies with who owns the process. If engineers own the process, then things can work. If non-engineers own the process, then you get the assembly-line mentality. Whether one calls it "Agile" is really irrelevant.

A lot of application software is fungible, boring, and just needs to get done. Agile helps with that.

No one is suggesting planning poker for qubit wiring.

"I myself am a master of the software arts - or an engineer if you want to be a dick about it"

https://www.youtube.com/watch?v=F4MCXotzJfA

"developer" if you're a canadian

Reply on news.ycombinator.com