Skip to content

Latest commit

 

History

History
executable file
·
301 lines (255 loc) · 18.8 KB

software-engineering.md

File metadata and controls

executable file
·
301 lines (255 loc) · 18.8 KB

Software Engineering

Consider ideas about industry software engineering. Could be combined with the notes in my blog repo?

I was looking at case studies for [[telematry]] and was thinking of practical uses

  • Dev Concepts Book (pre-order)

  • boringtechnology.club - Choose Boring Technology

    • Tried, tested, stable solutions ...

  • new codebase, who dis? (How to Join a Team and Learn a Codebase)

    • Setup dev environment
    • Get overview of architecture

  • Heuristics for Effective Software Development: A continuously evolving list

    • Without psychological safety, respect, and trust, none of the following is possible.
    • Process exists in service of people; the people come first.
    • The best ways to work are collaborative. Negotiation is not collaboration
    • Welcome change (you cant be rigid and agile)

  • Full Cycle Developers at Netflix — Operate What You Build

  • Planning & estimating large-scale software projects

    • A guide and formula

  • Engineering productivity can be measured - just not how you'd expect Antoine Boulanger 2021

    • AMAZING article
    • Mistake 1 - measure approximations of output
      • Developers game the system - seniors get board of the games
    • Mistake 2 - Measure nothing as its too complex
      • Long term motivation suffers as nothing matters
      • This system rewards charisma
    • The Solution: Measure Blockers at the Team Level
      • Blockers
        • Quality of developer tools
        • Frequency and quality of internal activities (like meetings or code reviews)
        • Focused maker time (free from disruptive meetings)
        • Easy access to documentation
        • Psychological safety on the team
        • Work-life balance
        • Presence of other high-performers
        • A fair system of rewards
      • Metrics
        • How much free, uninterrupted time does an engineer have to code?
        • How long is an engineer waiting on a response from another engineer's review?
        • How often do dev tools get in the way instead of helping accelerate work?
        • How often are engineers required to context switch, preventing deep work?
        • How often do engineers receive pages outside of business hours, interrupting their sleep or family life?
      • An engineering leader exists to enable their team to achieve their goals

  • SPACE

  • How to hire senior developers: Give them more autonomy

    • (insightful article about the value of code and the value of developers) - code is the manifestation of the the understanding of a problem
    • Your source code is worthless
    • The main value of a software company is the mapping of source code and problem space in the developer’s heads
    • developers should be given more responsibility and regarded as permanent assets to the company.
    • If you’re in a management position, you need to realize that development is mainly decision making, which of course only works if you’re given the necessary autonomy to make those decisions.

  • Software development topics I've changed my mind on after 10 years in the industry

  • What I’ve Learned in 45 Years in the Software Industry

  • "What if it changes?"

    • You can justify any complexity by 'speculation about change'.
    • Comedy rant
    • Stop making things so complex

  • What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not

    • "SV-like" companies think of engineers as value generators, and creative problem solvers. Traditional companies think of them as factory workers.

    1. Autonomy for software engineers

      • The expectation from developers at traditional companies is to complete assigned work. At SV-like companies, it's to solve problems that the business has.

    2. Curious problem solvers, not mindless resources

      • In practice, a motivated engineer easily makes multiple times the impact of a "factory worker" who is just told what to do

    3. Internal data, code, and documentation transparency
    4. Exposure to the business and to business metrics

      • In contrast, traditional companies often make it impossible for developers to interact with the rest of the business

    5. Engineer-to-engineer comms over triangle-communication

      • Traditional companies will encourage hierarchical communication

    6. Investing in a less frustrating developer experience

      • While it might sound counter-intuitive to hire software engineers who only focus on other software engineers working faster: at many places, it's not. It's a great return that helps these companies move faster, and developers stay happier.

    7. Higher leverage --> higher {autonomy, pay}

  • Software development topics I've changed my mind on after 6 years in the industry

    • Bad code can be written in any paradigm
    • Clever code isn't usually good code. Clarity trumps all other concerns
    • Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers
    • Code coverage has absolutely nothing to do with code quality

  • Maximizing Developer Effectiveness Martin Fowler 2021

    • Technology is constantly becoming smarter and more powerful. I often observe that as these technologies are introduced an organization’s productivity instead of improving has reduced. This is because the technology has increased complexities and cognitive overhead to the developer, reducing their effectiveness.
    • TODO: read this mand make notes

  • Meta-Design: A Manifesto for End-User Development

    • The seeding, evolutionary growth, and reseeding (SER) process model

  • Developers spend most of their time figuring the system out

    • Code is just data - when we make decisions about code, it's kind of data-science
    • We should never make decisions without knowing the

  • 7 behaviours to avoid in a software architecture role

  • ARCHITECTURE.md

    • Consider an ARCHITECTURE.md to describe the system

  • On navigating a large codebase

  • The Half Life of Code

  • Why does it take so long to build software? complexity, software design, thoughts

  • The Importance of Humility in Software Development

    • Dijkstra 1972
      1. The use of abstraction to make programs intellectually manageable
      2. Developing correctness proofs alongside the software
      3. Approaching the task of software development as humble programmers

        • brainpower is by far our scarcest resource

      • The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility

  • Programming, Motherfucker - Do you speak it?

  • 7 Absolute Truths I Unlearned as Junior Developer

    • Not all 'experience' is equal - home coding is different to commercial coding
    • Most compaies don't have tests to tech infra
    • Nitpicking over semicolons is pointless
    • Disorganised code != technical debt
    • Seniors need need more than raw code skill

  • Drunk Post: Things I've learned as a Sr Engineer

    • The best way I've advanced my career is by changing companies.
    • Technology stacks don't really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it's not going to be the same as webdev or embedded. But all fields have about 10-20 core principles and the tech stack is just trying to make those things easier, so don't fret overit.
    • I've made some good, lifelong friends at companies I've worked with. I don't need to make that a requirement of every place I work. I've been perfectly happy working at places where I didn't form friendships with my coworkers and I've been unhappy at places where I made some great friends.
    • If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.
    • Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.
    • The most underrated skill to learn as an engineer is how to document.
    • Related to above, writing good proposals for changes is a great skill.
    • The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me.
    • If I ever find myself thinking I'm the smartest person in the room, it's time to leave.
    • We should hire more interns, they're awesome. Those energetic little fucks with their ideas. Even better when they can question or criticize something. I love interns.
    • Speaking of titles: early in your career, title changes up are nice. Junior to Mid. Mid to Senior. Senior to Lead. Later in your career, title changes down are nice. That way, you can get the same compensation but then get an increase when you're promoted. In other words, early in your career (<10 years), title changes UP are good because it lets you grow your skills and responsibilities. Later, title changes down are nice because it lets you grow your salary.
    • I know enough about security to know that I don't know shit about security.
    • Being a good engineer means knowing best practices. Being a senior engineer means knowing when to break best practices.
    • If people are trying to assign blame to a bug or outage, it's time to move on.
    • It's not important to do what I like. It's more important to do what I don't hate.

  • High-Performance-Organizations-Reading-List

    • Amazing book summarys of LOADS of classic books
    • Not just computing - talks about organisation/societal structure
    • Some damning books about why agile is bad

  • MacPaint and QuickDraw Source Code

    • Measuring Lines of Code is a bad metric for programmers #metrics #history

  • Lock-in

  • Notes on Software Development Waste

    • Beautifully suucint list of where waste come in software projects

  • Sociotechnical Lenses into Software Systems

    • Software is ever changing. Our interactions and incidents as humans shape it.
    • Plot on graph
      • Releases
      • Incidents
      • Software Environment changes
      • Team leavers/join

  • Debugging unaligned project teams

    • WHY we’re doing anything
    • WHAT success looks like
    • WHO is responsible for doing it
    • HOW they’re going to do it
    • WHEN they’re going to do it

  • Famous laws of Software development

    • Murphys Law

      • If something can go wrong, it will.

    • Brook's Law

      • Adding manpower to a late software project makes it later.

    • Hofstadter's Law

      • It always takes longer than you expect, even when you take into account Hofstadter's Law.

    • Conways Law

      • Any piece of software reflects the organizational structure that produced it.

      • Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

    • Postel's Law aka Robustness principle

      • Be conservative in what you send, be liberal in what you accept

    • Pareto Principle aka The 80-20 rule

      • For many phenomena, 80% of consequences stem from 20% of the causes.

    • The Peter Principle

      • In a hierarchy, every employee tends to rise to his level of incompetence.

    • Kerchkhoff's Principle

      • In cryptography, a system should be secure even if everything about the system, except for a small piece of information - the key - is public knowledge.

    • Linus's Law

      • Given enough eyeballs, all bugs are shallow.

    • Moore's Law

      • The power of computers per unit cost doubles every 24 month.

      • The number of transistors on an integrated circuit will double in about 18 months.

      • The processing speed of computers will double every two years!

    • Wirth's law

      • Software gets slower faster than hardware gets faster.

    • Ninety-ninety rule

      • The first 90% of the code takes 10% of the time. The remaining 10% takes the other 90% of the time

    • [knuth]'s optimization principle

      • Premature optimization is the root of all evil.

    • Norvig's Law

      • Any technology that surpasses 50% penetration will never double again (in any number of months).

  • StackExchange: Project Management Why are developers expected to estimate tasks at all?

    • Because business gotta produce! - go agile!

    • We'll ask for estimates ... and then treat them as deadlines

  • SOC2: The Screenshots Will Continue Until Security Improves

    • #secutiry auditing for professional dev process - auditing/limiting who can commit to master

  • The disproportionate influence of early tech decisions

    • todo

  • Future: Infrastructure: What Is Negative Engineering?

    • Negative engineering is “insurance as code”
    • Plan for things going wrong
    • Example of a cron job not firing and the team not knowing until it was too late and none of the data had been collected.

  • RDEL #75: How do interruptions impact different software engineering activities?

    • Interruptions really REALLY affect productivity.
    • In person interruptions are more disruptive, but people don't seem to mind them as much