From 8599df6b920c412bfc1196a1d61c42344ca4e115 Mon Sep 17 00:00:00 2001 From: Caleb Rogers Date: Tue, 9 Jan 2024 22:52:58 +0800 Subject: [PATCH] Finish good engineering blog post --- src/blog/posts/good-engineering.html | 121 ++++++++++++++++++++++----- 1 file changed, 98 insertions(+), 23 deletions(-) diff --git a/src/blog/posts/good-engineering.html b/src/blog/posts/good-engineering.html index 75774ea..91874a2 100644 --- a/src/blog/posts/good-engineering.html +++ b/src/blog/posts/good-engineering.html @@ -44,7 +44,7 @@

After I got featured on Teddy Lai's Youtube channel in an interview, 508.dev membership has exploded. We now have around 60 members, up from the 15 or so we had - before. Before, I was able to one-on-one mentor people into the "508 style" of engineering, but now I think + before. Previously, I was able to one-on-one mentor people into the "508 style" of engineering, but now I think it's best to start with a primer, and from there mentor people into our style as needed.

@@ -58,6 +58,39 @@

and to help our engineers grow themselves professionally, I'm going to define these skills, as well as ones that deal with coding itself.

+

@@ -102,7 +135,7 @@

The easiest way to know what to work on next is to have it written down, probably in a TODO list. The easiest way to know what to work on after that is to have it written down, either in the same TODO list, or in some kind of project management solution, such as a kanban board. The easiest way to know what to work on when - you aren't sure what to work on is to have clearly defined the answer to this question before a question + you aren't sure what to work on is to have clearly defined the answer to this question before a project begins; we'll get into that more later.

@@ -188,38 +221,38 @@

I have thus developed a set of steps I require myself to go through before I ask for help, especially from a client.

-
    -
      +
        +
      1. Stare at the code for a decent amount of time, no matter how unreadable it is. -
      -
        + +
      1. If dealing with libraries or certain functions, ensuring to look at implementation details, methods, arguments available to a function, or other functions or components available from a library. -
      -
        + +
      1. Flip around some other files, some other places a given component is used, the UI itself (if ui code), or any other parts of the code base that might illuminate more info about the issue. -
      -
        + +
      1. Read any relevant documentation. If dealing with a library, looking at examples of their implementations. -
      -
        + +
      1. Google the issue I'm having. -
      -
        + +
      1. Stack overflow the issue I'm having. -
      -
        + +
      1. Ask ChatGPT questions to help me define the problem better (ChatGPT solutions themselves are almost never good and often are rabbit holes). -
      -
        + +
      1. Go for a walk, then repeat all the above steps. -
      -
        + +
      1. Do something else for a significant amount of time, then repeat all the above steps. -
      -
+ +

After I complete these steps, I consider myself having fulfilled my personal responsibility. Doing these helps avoid an embarrassing situation where a client issues a single line PR with an obvious fix, or linking @@ -331,6 +364,10 @@

certainly room for conversation about what code style is decided on, but the important thing is that one style is decided upon, and enforced.

+

+ For more information on writing good code, I recommend the famous + "The Pragmatic Programmer". +

@@ -364,8 +401,46 @@

ships with. At minimum, make sure to read up on the basics.

+

+ You should know how to do all of the following in git without needing to look it up or depend on Github's UI: +

+
    +
  • + Clone a repository +
    • +
  • + Create and push a new feature branch +
    • +
  • + Update a branch even if it has local changes that the remote doesn't have, and the remote has changes the local doesn't have +
    • +
  • + Merge branches locally +
    • +
  • + Resolve a merge conflict +
    • +
  • + Change a commit message in history +
    • +
  • + Merge two or more commits into one commit +
    • +
  • + See git history for a given file +
    • +
  • + See general git history for project +
    • +
  • + Use git to see who the last engineer to change a given line was, and in what commit they changed it +
    • +
  • + Push code for someone else to see, then soft reset to continue working as if you never made that commit +
    • +

-
+

Accessibility Standards