aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHolden Rohrer <hr@hrhr.dev>2021-05-05 19:57:46 -0400
committerHolden Rohrer <hr@hrhr.dev>2021-05-05 20:14:58 -0400
commitc6790d07794b1e59d41714c519aa84b646c4da13 (patch)
tree9bb7d31651ddb37083e876261b84553b43bea2d1
parent61b48fd8baae321daf294ebf670ef4906240d260 (diff)
wrote journal2
-rw-r--r--hireme/journal2.tex80
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