Dev

Collections

Teach Yourself Programming in Ten Years - Why is everyone in such a rush?
Google Style Guides
Hibernate should be to programmers what cake mixes are to bakers - This is a talk about the problems of creating convoluted abstractions and how not understanding what happens underneath makes things more complex instead of simplifying them.
How to transfigure wireframes into HTML
Does WWW still belong in URLs?
- WWW-less domain concern 1: Leaking cookies to subdomains
- WWW-less domain concern 2: DNS headaches
- WWW-less benefits
- WWW benefits
roadmap.sh - Community driven roadmaps, articles and resources for developers
https://github.com/sindresorhus/awesome - 😎 Awesome lists about all kinds of interesting topics
test && commit || revert
Limbo: Scaling Software Collaboration

Sort commits into “couldn’t possibly cause problems” (you’ll be mostly right) and “might cause problems”. Treat them differently. Rearrange your workflow so you have mostly “couldn’t possibly cause problems” commits.
Software effort estimation is mostly fake research
from HK news
- It's not fake research. It's actually quite an established science in the 24 years I've been doing it.
- Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it by the room temperature multiplied by the amount of people with mechanical keyboards.
- That gives you roughly the right estimate for any job, until the next sprint.
Nobody ever paid me for code
- Don't:
  
  We should migrate from SQLite to Postgress. We are getting concurrency errors because too many processes are trying to write orders at the same time and it's not something we can queue because it needs real-time feedback.
- Do:
  
  Some users are getting errors when too many of them order at the same time. We tried workarounds but they make for a bad shopping experience. This is not a trivial change to do. We are currently working on X, but I think this is more urgent. I advise we suspend work on X so that I can evaluate how much we need to do, and then plan for this change.
The Worst Programmer I Know

Tim wasn’t delivering software; Tim was delivering a team that was delivering software.
Measuring developer productivity? A response to McKinsey
Some notes on Local-First Development
- cr-sqlite - Convergent, Replicated, SQLite - "It's like Git, for your data."
People will never be motivated to go the extra mile by a standardized, bureaucratized process.
- https://news.ycombinator.com/item?id=39272190
Devin: AI Software Engineer - comments
- They actually dont do ANYTHING themselfs - Analytics: Hotjar, Website: NextJS, Login: Clerk, Jobs: Ashby, Waitlist: Google docs (ROFL), Learn more about their funding: A link to twitter
5 things I learned while developing a billing system
Doing is normally distributed, learning is log-normal
- Software estimation is challenging because it fails to recognize that learning is non-normally distributed.
Readme Driven Development
Drift towards danger and the normalization of deviance - systemic migration of organizational behavior toward accident under the influence of pressure toward cost-effectiveness in an aggressive, competing environment
- Overton window
소프트웨어 파괴의 미학

"소프트웨어 파괴의 미학"은 소프트웨어 개발에 내재된 불확실성을 탐구하며, 끊임없이 변화하는 비즈니스 요구사항 속에서 개발자들이 완벽을 추구하는 과정에서 직면하는 어려움을 강조합니다. 이 글은 개발자들이 품질을 위해 노력하지만 복잡한 비즈니스 역학에 직면하면서 기술 부채가 발생하는 과정을 설명합니다. 또한 Kano 모델을 참조하여 고객 만족도가 시간에 따라 어떻게 변화하는지, 한때 매력적이었던 기능들이 기본적인 기대사항이 되는 과정을 보여줍니다. 이 글은 코드가 결국 시대에 뒤처질 수밖에 없다는 사실을 받아들이고, 이러한 불가피성을 예상하고 받아들이는 마음가짐인 "Destruction-Oriented Development"의 개념을 소개합니다.
Focus on decisions, not tasks

In technical communication, we don’t talk much about decision support; we talk about task support… In many cases, the information people need to complete their tasks is not information on how to operate machines, but information to support their decision making… simply documenting the procedures is never enough… What I am talking about is documenting the context, letting users know what decisions they must make, making them aware of the consequences, and, as far as possible, leading them to resources and references that will assist them in deciding what to do. — Every Page Is Page One

re:Work

re:Work is a collection of practices, research, and ideas from Google and others to help you put people first.

Goal Setting Set goals to align efforts, communicate objectives, and measure process.
Hiring Make better hiring decisions through job descriptions, structured interviewing, hiring committees, and more.
Innovation Learn to build the skills for innovation and make it a part of your workplace.
Learning & Development Empower your employees to grow and develop by making learning part of everyone’s job.
Managers Identify what makes a great manager and offer feedback and development opportunities.
People Analytics Make informed, objective people decisions using science and data.
Teams Examine team effectiveness and how to foster psychological safety.
Unbiasing Reduce the influence of unconscious bias by educating, measuring, and holding everyone accountable.

Debug

Estimation

Pushing for a lower dev estimate is like negotiating better weather with a meteorologist

The article discusses how stakeholders often push development teams to provide lower estimates than initially given, without valid reasons for why the effort would decrease.

Estimates are based on teams' experience and data, not external opinions.
Estimates cannot be pushed lower without new information.

The better approach is to have a discussion around budget, uncertainties, and prioritization in order to deliver parts of the feature in a timely manner.

Teams are encouraged to ask stakeholders if they would tell a meteorologist their forecast is wrong, highlighting that estimates rely on expertise, not opinions.
With open communication around constraints and tradeoffs, teams can set appropriate expectations and deliver value along the way.

Code Assistance

LLMs and Programming in the first days of 2024

The author discusses their extensive use of large language models for programming tasks over the past year. They find LLMs most helpful for writing disposable code, learning new frameworks quickly, and accelerating documentation searches. While useful, LLMs still struggle with system programming problems requiring complex reasoning. The author believes LLMs have begun to show rudimentary reasoning abilities through their interpolation of concepts, but their capabilities are still limited. Overall, they argue LLMs are a valuable tool for programmers that can help focus time on more important problems and skills.

kevindamm

Salient point:

Would I have been able to do it without ChatGPT? Certainly yes, but the most interesting thing is not the fact that it would have taken me longer: the truth is that I wouldn't even have tried, because it wouldn't have been worth it.

This is the true enabling power of LLMs for code assistance -- reducing the activation energy of new tasks enough that they are tackled (and finished) when they otherwise would have been left on the pile of future projects indefinitely.

I think the internet and the open source movement had a similar effect, in that if you did not attempt a project that you had some small interest in, it would only be a matter of time before someone else did enough of a similar problem for you to reuse or repurpose their work, and this led to an explosion of (often useful, or at least usable) applications and libraries.

I agree with the author that LLMs are not by themselves very capable but provide a force multiplier for those with the basic skills and motivation.

nickpsecurity

I had good results by writing my requirements like they were very, high-level code. I told it specifically what to do. Like formal specifications but with no math or logic. I usually defined the classes or data structures, too. I’d also tell it what libraries to use after getting their names from a previous, exploratory question. From there, I’d ask it to do one modification at a time to the code. I’d be very precise. I’d give it only my definitions and just the function I wanted it to modify. It would screw things up whereby I’d tell it that. It would fix its errors, break working code with hallucinations, and so on. You need to be able to spot these problems to know when to stop asking it about a given function.

I was able to use ChatGPT 3.5 for most development. GPT 4 was better for work needed high creativity or lower hallucinations. I wrote whole programs with it that were immensely useful, including a HN proxy for mobile. Eventually, ChatGPT got really dumb while outputting less and less code. It even told me to hire someone several times (?!). That GPT-3-Davinci helped a lot suggests it’s their fine-tuning and system prompt causing problems (eg for safety).

The original methods I suggested should work, though. You want to use a huge, code-optimized model for creativity or hard stuff, though. Those for iteration, review, etc can be cheaper.

Children