Skip to content

Latest commit

 

History

History
71 lines (42 loc) · 3.26 KB

sprint05.md

File metadata and controls

71 lines (42 loc) · 3.26 KB

Sprint 5 (In-Person 2): Vanilla JS

JS and APIs

by Roger Mullins

Click Here to Return to the Main Page

What did you learn about that helped you understand the development process?

Several concepts we covered this week stand out to me.

UX/UI Design

Whether or not 'we' as developers have a natural talent for design is beside the point, really, when you factor in that we're also all users. It's worthwhile to take a step back from the logic problem of a new assignment to imagine, first, what would constitute a pleasant user experience. I have found especially with pseudocoding that a quick walk-through of UX is invaluable for planning the structure and flow of the program itself.

Pareto Principle

It's easy to get carried away adding features to a project, but the Pareto Principle reminds us of the law of diminishing returns. Rather than packing a project with a ton of cool features that will ultimately be ignored by 80% of the people actually using our product, we would be better served (as would be our end user) by polishing and perfecting the small sub-set that will actually be central to the user experience.

Packages and APIs

While I was conceptually aware of outside libraries and data sources, this week was the first week where we really started to use them. I can see where this would be invaluable in the design project if only for the simple purpose of not re-inventing the wheel on every coding challenge.

What does it mean to develop good code?

'Good' code should be

  • Easy to read
  • As concise as possible for the task at hand
  • Modular or reusable if possible
  • Actually functional

(Not necessarily in that order).

With the possible exception of research notes, I haven't seen anything that goes stale faster than source code. I can go back to code I wrote last week and have to take a minute to figure out what I was doing. That's why I try to leave comments throughout to try and remind myself what I was doing and why.

What does it mean to be a good developer?

'Good' developers should be

  • Willing to learn
  • Willing to learn, and
  • Willing to learn

There's no such thing as the 'only' way to do something. Some approaches may be better than others and some worse, but in my experience it's always instructive to really understand why that's so.

It's easy to submit a kata solution and immediately feel dejected because someone did the same thing in one line. But there will always be somebody better at things. The key is to learn from that person rather than getting caught up in comparison.

What is one thing that programmers hate doing?

Repeating code.

Questions or comments? Contact the Author