aboutsummaryrefslogtreecommitdiff
path: root/hireme/journal2.tex
blob: 611cf76ab815f2ca3784b5b4fbd0462f43375b95 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
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