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

The best programmers I know

endler.dev

Post reply on HN
Print view View original

301–310 of 320 posts

Re: The best programmers I know

#301

Post by pydry »

necovek wrote: post #300
pydry wrote: post #99

Earlier quoted context omitted.

Im somewhat puzzled as to why so many devs are insistent that being a good developer means you need to be a good PM. These roles require wildly different skills and knowledge. Usually the outcomes are better if you combine two people who are good at their jobs rather than hoping one person can do it all.

Good engineering skills are transferable to being a good PM: you need to break down problems, scope them to fit a particular time allotment, estimate an effect on user experience (stats, tracking, what is a good signal and what isn't) and have the agility to react to changing requirements as things are getting built. Why it makes sense for them to be a single person? Often, "changing requirements" really comes from a…

Breaking down problems (vertical slicing) isnt inherently a dev skill. Insofar as it is a transferable skill to break down problems it is more of a life skill.

Scoping tickets is more of a project management skill. Again, not a dev skill.

Estimating effect on user experience - requires empathy, again not a dev skill.

If you redefine the dev job as including PM skills then sure, PM skills are dev skills.

But theyre not.

>Why it makes sense for them to be a single person? Often, "changing requirements" really comes from an engineer learning new things

So? Happens to me too. I can tell the PM these things i learned. Thats a hell of a lot easier than managing all stakeholder interactions, empathizing and balancing their demands.

It only really makes sense to combine the two roles if the project is inherently very straightforward, a salary can be saved and the person doing both roles is suffiently qualified for both roles.

Re: The best programmers I know

#302

Post by zero_shift »

ryandrake wrote: post #212
yobbo wrote: post #80

Earlier quoted context omitted.

Yep. A developer with "business impact" might be seen as a liability. One aspect might be that a developer who engages in "business" effectively stops being "subordinate". Management decisions need to be justified on a different level to maintain legitimacy.

This thread is kind of wild and something I've never heard anywhere in tech. Every place I've worked would consider a developer at least 5X more valuable if they actually had business or product sense, and could operate without the need for constant symbiosis with a "product guy". At one BigTech company we've all heard of, our division didn't even have product people. The engineering lead was expected to handle all o…

That sounds great, and I would advise you to value it. Most tech companies are not this forward thinking (often to their own detriment)

Re: The best programmers I know

#303

Post by pc86 »

whstl wrote: post #295
pc86 wrote: post #220

Earlier quoted context omitted.

The problem is that for every example like yours where you run into very specific ORM edge cases, and seems completely reasonable, there are about 95 where a story like this is used as justification to spend months building something when a library would have actually worked out just fine and been implemented in weeks or days. And that running into these edge cases is used as justification for "throw the ORM out" not…

Entity Framework is in a completely different class from pretty much every ORM out there, with only a handful of exceptions. Even ActiveRecord in Rails is a toy compared to it. Even back when it was launched EF was miles ahead of most mature ORMs of today, and I believe your 95% number. But other than EF plus a handful of other mature ORMs, the 95% number looks more like 50%. I would even argue that new-ish ORMs are…

I've yet to find a simple-to-moderately-complex CRUD use case that Supabase can't handle with almost no manual configuration required. There are a few postgres things they hide that you need for more advanced uses but overall it's a great product especially if you're willing to go full vendor lock-in and use them for auth, blob storage, etc.

I have a side project that uses Clerk for auth but basically every other supabase product there is and it really is great for smaller use cases. I don't know how it stacks up once you start needing really fine-tuned database permissions or functionality though.

Re: The best programmers I know

#304

Post by skydhash »

socksy wrote: post #178
ctxc wrote: post #173

Earlier quoted context omitted.

This is why I tend to Google instead of chatgpt everything. I always end up finding these little interesting nuggets in comments/threads in SO

I think my preferred LLM usage style these days is to try something on my own, and then get the LLM to critique what I did. I think it's both better for learning (just like learning natural languages, it's better for learning to make a mistake and be corrected than it is to look up the right answer each time), and also I think the stakes are lower since you're not relying on the LLM to not hallucinate. You can also l…

If I’m writing in an unfamiliar language or using an unfamiliar library, I will mostly have several browser tabs opened. That’s because the docs usually have caveats and other tips that will be missing from LLMs. And a book can do wonders for strengthening your foundations.

Re: The best programmers I know

#305

Post by skydhash »

asl2D wrote: post #123
kshri24 wrote: post #51

Can't find any fault in this article. Agree with pretty much everything except for one point: "Don’t go to Stack Overflow, don’t ask the LLM, don’t guess, just go straight to the source. Oftentimes, it’s surprisingly accessible and well-written." It has been, I think, close to 15+ years since I have been actively coding professionally. I am always learning. When I started my career I spent a fair bit of time answerin…

I recently started drawing (my own little middle age crisis) and i am so out of depth, so far from even understanding what is possible, and the internet filled with so much junk tutorials, that sometimes ability of LLM to parse my intent and guide me towards the key words and names is a godsend, of course it probably would be better to ask a person who knows this stuff, but it's not always convenient. In my use case…

For drawing it’s usually better to buy a book or a course (from a good platform like New Masters Academy), and then practice (a lot)

Re: The best programmers I know

#308

Post by whstl »

pc86 wrote: post #303
whstl wrote: post #295

Earlier quoted context omitted.

Entity Framework is in a completely different class from pretty much every ORM out there, with only a handful of exceptions. Even ActiveRecord in Rails is a toy compared to it. Even back when it was launched EF was miles ahead of most mature ORMs of today, and I believe your 95% number. But other than EF plus a handful of other mature ORMs, the 95% number looks more like 50%. I would even argue that new-ish ORMs are…

I've yet to find a simple-to-moderately-complex CRUD use case that Supabase can't handle with almost no manual configuration required. There are a few postgres things they hide that you need for more advanced uses but overall it's a great product especially if you're willing to go full vendor lock-in and use them for auth, blob storage, etc. I have a side project that uses Clerk for auth but basically every other sup…

Yep, that's also my experience, my current job uses it for some products.

I find it that if you accept Supabase as-is, it can get you pretty far and save a lot of time and money.

And for edge cases, it's like you said above about ORMs, we don't have to throw it out, we just handle those cases separately.

Re: The best programmers I know

#309

Post by roguecoder »

Taek wrote: post #133
bob1029 wrote: post #103

Not guessing is perhaps the most important thing to the business. I developed a lot of my problem solving skills in semiconductor manufacturing where the cost of a bad assumption tends to be astronomical. You need to be able to determine exactly what the root cause is 100% of the time or everything goes to hell really fast. If there isn't a way to figure out the root cause, you now have 2 tickets to resolve. I'll thr…

I always get a lot of pushback for avoiding frameworks and libraries, and rolling most things by hand. But, most frameworks and libraries aren't built to be audit-grade robust, don't have enterprise level compatibility promises, can't guarantee that there won't be suprise performance impacts for arbitrary use cases, etc. Sometimes, a third party library (like sql-lite) makes the cut. But frameworks and libraries that…

Frameworks are just someone else's architecture.

They are helpful if you have the same problems as that other company, but I worry about software that uses frameworks because the programmers don't feel confident building their own. It means when it comes time to evolve beyond the off-the-shelf architecture, programmers keep plowing ahead far past when they should have added another level of abstraction & encapsulation.

On the other hand, I also see applications where people dogmatically avoid using pre-existing architectures but also don't take the time to build their own. You end up with references to one table scattered all across the code base in hand-composed SQL.

I'd much rather take an outgrown-framework over a spaghetti mess.

Re: The best programmers I know

#310

Post by roguecoder »

zero_shift wrote: post #61
blackbrokkoli wrote: post #22

Note that this says "best programmers" not "people best at having business impact by making software". I wonder about this often: If you want to have impact/solve problems/make money, not just optimizing killing your JIRA tickets, should you invest a given hour into understanding the lowest code layer of framework X, or talk to people in the business domain? Read documentation or a book on accessibility in embedded s…

Generally we aren't paid for our business expertise. In fact, most businesses actively resist giving developers deep domain responsibility. This is manifest in management methodologies: developers are largely interchangeable cells in a spreadsheet. I'm not saying this is a good thing. The reasons for this are complex, but generally, business people want us to solve the technical problems they can't handle themselves,…

The result of that top-down management style is buggy code, blown deadlines, security holes, and the slowest software development I've ever seen.

I've found it possible to migrate to a less top-down Desert style just by finding executives who are frustrated by those problems and saying, "I have an idea I've seen help" and then getting the team together and saying, "hey, it turns out the executives would like us to write software well. What should we try first?"

Product has plenty of work remaining: they should be handling whatever subset of strategy, prioritization, analytics, BI, QA, facilitation, design and contracts that they have the skills for. But it requires engineers to actually collaborate with them as a peer, rather than engage in power struggles, and that requires everyone on the team to understand what we are building, for whom, and why.

Post reply on HN