34 Matching Annotations
  1. Last 7 days
    1. Getting hooked on computers is easy—almost anybody can make a program work, just as almost anybody can nail two pieces of wood together in a few tries. The trouble is that the market for two pieces of wood nailed together—inexpertly—is fairly small outside of the "proud grandfather" segment, and getting from there to a decent set of chairs or fitted cupboards takes talent, practice, and education.

      This is a great analogy

    2. the Peter Principle, the idea that in an organization where promotion is based on achievement, success, and merit, that organization's members will eventually be promoted beyond their level of ability

      Applying the principle to software, you will find that you need three different versions of the make program, a macroprocessor, an assembler, and many other interesting packages. At the bottom of the food chain, so to speak, is libtool, which tries to hide the fact that there is no standardized way to build a shared library in Unix. Instead of standardizing how to do that across all Unixen the Peter Principle was applied and made it libtool's job instead.

  2. Apr 2024
    1. This is not a discrete project but an ongoing process and should always be competing for focus in strategic decision making.

      Absolutely agreed. One limitation of the Iron Triangle concept is that it often seems to be used to make decisions based on a snapshot in time (i.e. which two are we choosing now), when some choices have longer half-lives than others.

  3. Mar 2024
    1. By jumping into unfamiliar areas of code, even if you do not "solve" the bug, you can learn new areas of the code, tricks for getting up to speed quickly, and debugging techniques.

      Building a mental model of the codebase, as Jennifer Moore says over at Jennifer++:

      The fundamental task of software development is not writing out the syntax that will execute a program. The task is to build a mental model of that complex system, make sense of it, and manage it over time.

    2. Thinking about how you will observe whether things are working correctly or not ahead of time can also have a big impact on the quality of the code you write.

      YES. This feel similar to the way that TDD can also improve the code that you write, but with a broader/more comprehensive outlook.

  4. Aug 2023
    1. Global Engineering

      Unleash the power of custom software! Hey, business owner! Tired of one-size-fits-all software solutions? It's time to go custom! At GlobalDev, we're wizards of custom software development services. We understand your unique needs and tailor software that fits like a comfy pair of sneakers. With us, you get top-notch quality and flexibility—just the way you like it!

  5. Jun 2023
    1. Platform engineering is trying to deliver the self-service tools teams want to consume to rapidly deploy all components of software. While it may sound like a TypeScript developer would feel more empowered by writing their infrastructure in TypeScript, the reality is that it’s a significant undertaking to learn to use these tools properly when all one wants to do is create or modify a few resources for their project. This is also a common source of technical debt and fragility. Most users will probably learn the minimal amount they need to in order to make progress in their project, and oftentimes this may not be the best solution for the longevity of a codebase. These tools are straddling an awkward line that is optimized for no-one. Traditional DevOps are not software engineers and software engineers are not DevOps. By making infrastructure a software engineering problem, it puts all parties in an unfamiliar position. I am not saying no-one is capable of using these tools well. The DevOps and software engineers I’ve worked with are more than capable. This is a matter of attention. If you look at what a DevOps engineer has to deal with day-in and day-out, the nuances of TypeScript or Go will take a backseat. And conversely, the nuances of, for example, a VPC will take a backseat to a software engineer delivering a new feature. The gap that the AWS CDK and Pulumi try to bridge is not optimized for anyone and this is how we get bugs, and more dangerously, security holes.
  6. Jan 2023
    1. Deploy engines as separate app instances and have them only communicate over network boundaries. This is something we’re starting to do more.

      Before moving to this microservice approach, it's important to consider whether the benefits are worth the extra overhead. Jumping to microservices prematurely is something I've seen happen more than once in my career, and it often leads to a lot of rework.

  7. Dec 2022
    1. While you might think that pairing less experienced engineers is a waste of time, every single time I had a less experienced engineer work by themselves, I ended up regretting it.

      This has been my experience this year

  8. Nov 2022
  9. Jul 2022
    1. The major benefit of foreign keys is that they guarantee referential integrity. For example, say you have customers in one table that may refer to a number of invoices in another. Without foreign keys, you could delete a customer, but forget to remove its invoices, thereby leaving a bunch of orphaned invoices that reference an customer that’s gone.

      Note that GH doesn't use FK (at least back in 2016) https://github.com/github/gh-ost/issues/331#issuecomment-266027731 due to: * MySQL doesn't support it on partitioned tables * Performance impact. * FKs don't work well with online schema migrations

      From Postgres has foreign keys to be fully compatible with partitioned tables since 12. But still it's not that commonly used for larger DBs.

    2. If an operator ever queries the database directly they’re even more likely to forget deleted_at because normally the ORM does the work for them.

      This happens relatively often, especially for 1) engineers that run SQL queries directly against the DB for analysis or triaging production issues, and 2) data scientists that do not use the same programming language as the enginners

  10. Jan 2022
    1. When a product manager trusts that the engineers on the team have the interest of the product at heart, they also trust the engineer’s judgment when adding technical tasks to the backlog and prioritizing them. This enables the balanced mix of feature and technical work that we’re aiming for.

      Why is it so common for engineering teams to be mistrusted by other parts of the business?

      Part of that is definitely on engineers: chasing the new shiny, over-engineering, etc.

      That seems unlikely to account for all of it, though.

  11. Aug 2021
    1. An interesting directory of personal blogs on software and security.

      While it aggregates from various sources and allows people to submit directly to it, it also calculates a quality score/metric by using a total number of Hacker News points earned by the raw URL

      Apparently uses a query like: https://news.ycombinator.com/from?site=example.com to view all posts from HN.

  12. Apr 2021
    1. Coordination: More environments require more coordination. Teams need to track which feature is deployed to which environment. Bugs need to be associated with environments. Every environment represents a particular ‘state’ of the codebase, and this has to be tracked somewhere to make sure that customers & stakeholders are seeing the right things;

      Try to remember the last time you heard one of the following phrases:

      • "Oh, I deployed it in the X environment"
      • "It was working in the stage environment"
  13. Mar 2021
    1. Sorry you’re surprised. Issues are filed at about a rate of 1 per day against GLib. Merge requests at a rate of about 1 per 2 days. Each issue or merge request takes a minimum of about 30 minutes (across at least 2 people) to analyse, put together a fix, test it, review it, fix it, review it and merge it. I’d estimate the average is closer to 3 hours than 30 minutes. Even at the fastest rate, it would take 3 working months to clear the backlog of ~1000 issues. I get a small proportion of my working time to spend on GLib (not full time).
  14. Feb 2021
    1. “Functional programming language” is not a clearly defined term. From the various properties that are typically associated with functional programming I only want to focus on one: “Immutability” and referential transparency.

      I mean not clearly defined seems wrong, there are common accepted characteristics that make a language functional.

  15. Nov 2020
  16. Oct 2020
    1. One of the primary tasks of engineers is to minimize complexity. JSX changes such a fundamental part (syntax and semantics of the language) that the complexity bubbles up to everything it touches. Pretty much every pipeline tool I've had to work with has become far more complex than necessary because of JSX. It affects AST parsers, it affects linters, it affects code coverage, it affects build systems. That tons and tons of additional code that I now need to wade through and mentally parse and ignore whenever I need to debug or want to contribute to a library that adds JSX support.
  17. Jun 2020
    1. An Idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.
    2. A Design Pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.
    3. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.
    4. patterns are considered to be a way of putting building blocks into context
    5. A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in others"
  18. Feb 2019
    1. INVEST

      According to this checklist, a User Story should be:

      Indepedent (of all others)

      Negociable (not a specific contract for features)

      Valuable (or vertical)

      Estimable (to a good approximation)

      Small (so as to fit within an iteration)

      Testable (in principle, even if there isn't a test for it yet)

      Source(s):

      1. Glossary: INVEST - Agile Alliance
      2. INVEST at XP 1-2-3 by Bill Wake
  19. Jan 2017
  20. Nov 2016
  21. May 2016
    1. As such, scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly, to respond to emerging requirements and to adapt to evolving technologies and changes in market conditions.

      算法开发工作就有这种特点

  22. Apr 2016
    1. the study of innovation shows that everything hinges on the hard work of taking a promising idea and making it work — technically, legally, financially, culturally, ecologically. Constraints are great enablers of innovation.
    2. But there’s a downside to the hackathon hype, and our research on designing workplace projects for innovation and learning reveals why. Innovation is usually a lurching journey of discovery and problem solving. Innovation is an iterative, often slow-moving process that requires patience and discipline. Hackathons, with their feverish pace, lack of parameters and winner-take-all culture, discourage this process. We could find few examples of hackathons that have directly led to market success.
    3. what if projects were designed to combine a hacking mindset with rigorous examination of the data and experience they glean? This would reward smart failures that reveal new insights and equip leaders with the information needed to rescale, pivot or axe their projects.

      Sounds somewhat like agile devlopment.

  23. Feb 2016
    1. In summary, teams which are "fairer", in two senses, tend to be more effective:

      • Those where members speak and contribute in roughly the same proportion (albeit possibly in quite different ways)
      • Those where members have an above-average sensitivity to what others are thinking and feeling