Dev

Collections

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
  1. 21 Lessons from 14 Years at Google
  2. AI
  3. Advice for new software devs who've read all those other advice essays
  4. Algorithms we develop software by
  5. Auth
  6. Back End
  7. Bdd in 2020
  8. Best Practices
  9. Building Software Together
  10. CLI
  11. CSS
  12. Code Review
  13. Cognitive load is what matters
  14. Comments
  15. DB
  16. Dev Tools
  17. Devops
  18. Etc
  19. Functional Programming
  20. Fundamental Math for Game Developers
  21. Git
  22. Greppability is an underrated code metric
  23. HTML
  24. Hammock Driven Development - Rich Hickey
  25. Hardware
  26. If You Thought the Speed of Writing Code Was Your Problem You Have Bigger Problems
  27. Infrastructure
  28. Inside ECMAScript: JavaScript Standard Gets an Extra Stage
  29. Interesting
  30. Interview
  31. JavaScript
  32. Journal
  33. Kind Engineering
  34. Learning at Work
  35. Management
  36. Miscellaneous
  37. Network
  38. PHP
  39. Practices of Reliable Software Design
  40. Privacy
  41. Program Languages
  42. Pronunciation guide for UNIX
  43. Python
  44. Reading List
  45. Regex
  46. Rust
  47. SaaS Payment vs. SaaS Billing - What Those Terms Mean and What the Differences Are
  48. Security
  49. Side Project
  50. Software Component Names Should Be Whimsical and Cryptic
  51. Software Engineering
  52. Team
  53. Terminology
  54. Test
  55. The Rise of Worse is Better
  56. To Fork
  57. To Read List
  58. Topcat's System Design Template
  59. TypeScript
  60. UX
  61. Virtualize
  62. Web
  63. What to Blog About
  64. Why Not Comments
  65. With AI
  66. You should separate your billing from entitlements
  67. ๐Ÿฆ‘ The 14 pains of building your own billing system