diff options
author | Holden Rohrer <hr@hrhr.dev> | 2021-05-05 19:57:46 -0400 |
---|---|---|
committer | Holden Rohrer <hr@hrhr.dev> | 2021-05-05 20:14:58 -0400 |
commit | c6790d07794b1e59d41714c519aa84b646c4da13 (patch) | |
tree | 9bb7d31651ddb37083e876261b84553b43bea2d1 | |
parent | 61b48fd8baae321daf294ebf670ef4906240d260 (diff) |
wrote journal2
-rw-r--r-- | hireme/journal2.tex | 80 |
1 files changed, 80 insertions, 0 deletions
diff --git a/hireme/journal2.tex b/hireme/journal2.tex new file mode 100644 index 0000000..611cf76 --- /dev/null +++ b/hireme/journal2.tex @@ -0,0 +1,80 @@ +\font\twelverm=ptmr7t at 12pt +\twelverm +\baselineskip=24pt +\nopagenumbers +\headline={\hfil Rohrer \number\pageno} +{\obeylines +Holden Rohrer +Ms Rosner +Hire Me +2 Apr 2021} + +\centerline{Journal Prompt \#2: Time Management} + +Time-management is critical, in general, for managing various tasks' +completion over time. +The processes by which we do these are important to maintain and to pay +attention to. +To manage my time, I and many others use several solutions: calendars, +to-do lists, time estimations, emails, discussions over scheduling, etc. +These tools are helpful in figuring out what I have time to do and when +something needs to be done and whether or not their is a conflict or an +issue with coordinating an event like a meeting. +This is both a generally true issue and an issue thatgs relevant to the +internship, school/academics, and to my possible future career in +software development. + +There are a few different layers of time management: discrete scheduling +to determine conflicts and coordinate different schedules, time +allocation, and priority management. +The first kind is the simplest and least creative: one just needs to +figure out how long an event will last and any specific times it needs +to start/end by in order to allocate time like this. +Managing conflicts can be somewhat difficult and can require some +difficult either-or choices, but much of the time, one event or another +can be rescheduled. +After time for meetings or events have been set, itgs fairly easy to do +them, but there isngt any guarantee that the work or decisionmaking will +be finished by the time the meeting is over. + +This leads into the second kind of time management, generally project +management. +This kind focuses on the productive output of a person or a group of +people, and theregs a lot of philosophies about the best way to do it, +including some common pitfalls in measuring productivity. +One of these is ``linearization.'' +In The Mythical Man Month, Frederick Brooks remarks on how software +project management struggles under a variety of misguided reforms and +strategies to complete projects. +Linearization is trying to add more people to a project in order to +complete it faster, whereas this actually slows down progress because +engineers get in each others' way when trying to collectively build +software. +There are some ways to try to get around this, and 7Factor uses some of +them. Currently, the zeitgeist in software engineering is strategies +like kanban and Agile or Scrum, in contrast to traditional ``waterfall'' +project management. +7Factor uses kanban, where client requests and bugfixes are isolated +into individual tickets/stories that team members can pick up and put +down as the need arises. +This allows for greater throughput of the team without sacrificing +responsiveness to client requests. + +As an individual software engineer, a lot of time management is just +putting work-hours into this system in order to complete tasks, but when +actually working in industry, a few more very time-sensitive or +time-specific tasks appear. +Client meetings, stand-ups, and architecture meetings are some of the +biggest uses of time which are essential to the work. +These are meetings where software engineers and the people who will use +the software discuss how time will be allocated by the time and on what +schedules projects need to be finished in. +However, even if a schedule is decided in advance, itgs often more +important to continuously communicate how exactly the process is going +(if, for example, a feature is running late and will not be delivered on +time, or if wishlist items need to be sacrificed in order to deliver on +time) than to rush to complete things on crunch. +This is a strategy that Game Development companies use, and it leads to +developer burnout, meaning the code gets harder to maintain over time. + +\bye |