
Absolute truths I unlearned as junior developer - dcu
https://monicalent.com/blog/2019/06/03/absolute-truths-unlearned-as-junior-developer/
======
beat
Admittedly, my first days as a junior programmer were before some of you were
born, but I'm thinking of a particular format here...

Learned as junior: If you report an OS bug or some other deep problem, seniors
will not believe you and assume you're making excuses for your own bugs and
lack of understanding.

Understood as senior: If a junior programmer tells me they found a system-
level bug, I won't believe them and will tell them to go figure out what's
wrong with their code.

Learned as junior: Legacy code is hard to read.

Understood as senior: Legacy code _that I wrote myself_ is hard to read.

Learned as junior: Technical skills matter most.

Understood as senior: Communication skills matter most.

Learned as junior: New tech solves old problems.

Understood as senior: New tech creates new problems.

~~~
enobrev
> code that I wrote myself is hard to read

This has happened more times than it probably should:

1\. Arrive upon some code I wrote at some point in the near or distant past.

2\. Review it to get some idea of what I was trying to do

3\. Laugh at my young self for being so naive

4\. Refactor or Rewrite

5\. Re-realize the edge-cases and difficulties

6\. Remember this being a problem

7\. Refactor And Rewrite

8\. Either `git reset --hard HEAD` or end up with a similar solution, but with
better comments

Once in a while, I end up with a [simpler | faster | clearer | otherwise
better] version, which makes this process worth while - even with the false
positives.

~~~
snicky
Semi-related story of mine:

1\. Stumble upon some specific problem with a web framework we use.

2\. Jump straight to stackoverflow.

3\. Sbd had a similar issue, nice.

4\. Sbd wrote a very concise answer, nice too.

5\. There's my nickname under the answer. Oh, wait...

~~~
Buge
Does "Sbd" stand for something, or is that your username?

~~~
taatparya
Somebody

~~~
PunksATawnyFill
Uh, OK. Never seen that before.

"Sby" would've made way more sense. Or heaven forbid we use one more character
to make the nearly obvious "sbdy."

------
taneq
The big one for me was the realisation that _the code doesn 't matter_. I mean
sure, it does, to us. It's what we do. But really, code doesn't matter.

To the end user, what matters is that we solve their problem. We let them do
their job, and we make that job as easy as possible. And that's what they pay
us for.

And to the company we work for, what matters is that we solve the end user's
problem, and that we do so in an expedient and economical manner, so that it
costs less for us to do so than the customer pays us.

Of course, for us to _continue_ doing this, in the long term, we need to
innovate and architect and uphold standards and stay on top of technical debt.
And all of that put together is "make the code good". But that's an end to the
means, and the customer doesn't care what horrors awake when they click that
dialog box button as long as the result they needed pops out at the end.

~~~
pdpi
This is why calling people "coders" annoys the hell out of me. There was a
popular blog post a long way back[1] about how you shouldn't call yourself a
"programmer" because that builds the expectation that programs are the key
output of your work. "Coder" takes this problem even further — your job is no
longer to build a program (with all the thought and design work that entails),
but rather to type out code.

I'm not a coder, or a programmer. I'm a problem solver, and I tend to
specialise in the sort of software infrastructure-y problems that are usually
solved through code. If you think of yourself as a problem solver first and
foremost, then you'll often realise that the best solution involves zero code.

This ${problem}-solver versus ${solution}-user gets even worse when people go
beyond define themselves as technology-du-jour users, doesn't matter if it's
Rails, React, blockchains, big data, ML, AI...

1\. [https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-
pr...](https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

~~~
RussianCow
This is why I always respond to questions about what I do with "software
engineer". I've noticed people seem to perceive "engineering" as more serious
than "programming", and it helps to promote the idea that I build things to
solve problems and don't just sit there turning designs into code.

~~~
patagonia
From Wikipedia:

Engineers, as practitioners of engineering, are people who invent, design,
analyse, build, and test machines, systems, structures and materials to
fulfill objectives and requirements while considering the limitations imposed
by practicality, regulation, safety, and cost.

If you’re doing that you’re an engineer. Hopefully we are all doing that.

~~~
monocasa
Unless you're in certain states where engineer is a protected term.

~~~
ghaff
Engineer is not a "protected term" in any US state that I'm aware of.
"Professional Engineer" has a specific licensed meaning but, if I have a
degree in mechanical engineering I'm pretty sure I can call myself an engineer
anywhere in the US without the licensing police coming after me. (Unless, of
course, I imply that I'm licensed when I'm not.)

~~~
nobleach
If you work in a music studio, and you call yourself a sound engineer, no one
is going to ask to see your credentials because it's assumed that you engineer
sound. The same holds through with software engineering. No one expects you to
carry some sort of card. When it comes to structural, or civil engineering,
there is a far higher expectation that the things you design are not going to
fall down. But we're able to understand this distinction. The idea that we
should disallow computer coders/programmers from using the term engineer is
not based on reducing confusion...

~~~
ghaff
>When it comes to structural, or civil engineering, there is a far higher
expectation that the things you design are not going to fall down.

The big thing is that you need a P.E. in many cases to do things like sign off
on drawings for regulators. Some civil engineers, mechanical engineers, etc.
have PE's and many don't. In Louisiana, I had business cards with an
engineering title and definitely worked as an engineer. At some point, had I
remained in the oil business, I'd have gotten a PE because I'd presumably have
eventually been in a position where I had approval authority over designs
submitted to various government agencies.

------
docker_up
Overall a good article, but I completely disagree with the notion that "good
enough is good enough".

I've been in a lot of code reviews where developers push back because it's
"good enough". You need to maintain a defined level of quality otherwise
codebases go to shit very, very fast.

I was recently told in a code review that a Cassandra read before a write (to
ensure there were no duplicates) was "good enough" because a duplicate
"probably wouldn't happen very often". Meanwhile, the consequences of a dupe
would lead to a pretty bad customer experience.

I pushed back hard and forced the developer to rewrite his entire code. Would
"good enough" be okay in this situation? My bar is much higher than this
developer and I stand by my decision. We have the luxury of being tasked with
solving customer problems and if we only strive for "good enough" every time
instead of "the best I can do within the constraints I'm given", then in my
opinion your career won't be very successful. We always have to make the best
tradeoffs when it comes to time and expense, but the best developers are the
ones that come up with the best solution and the best code that fits in a
particular constraint.

~~~
rafiki6
I'm going to challenge you here (admittedly without full context, but to make
a point). It sounds to me like the problem you're describing requires a
database has ACID transactions which is not Cassandra. Therefore Cassandra is
a poor choice and in my view that is poor engineering. This being said, I'd
err on the side of agreeing with the developer who determined that they are
not capable of writing code that guarantees ACID transactions in Casandra
(that's a hard thing to do), and I'd really question the choice to use it to
begin with.

Again without appropriate context, my bet here is that you guys are using
Cassandra for other important features you won't get out of a typical RDBMS
and as such you made a trade off to begin with and decided that Cassandra was
"good enough".

Now the point I'm trying to illustrate (and I'm not just doing this to pick a
fight, I promise), is that engineering is about trade offs and a big part of
it is definitely related to likelihood of a problem occurring.

I think it also completely depends on the domain of the problem, the
criticality of the process you're building and the outcome of a major failure
of your assumptions.

So I'd just argue and say "good enough" is an entirely appropriate answer in
many contexts and domains and it's important not to make a blanket assumption
that it's wrong.

~~~
docker_up
We aren't in disagreement, and I don't take your comment as a challenge, it
was exactly something we went through with this feature. The point is, who
gets to decide what "good enough" is? The difference between my "good enough"
is a lot different than my coworker's "good enough", and I think that's what
separates levels of maturity as a developer.

In fact Cassandra wasn't my first choice, but a strongly consistent database
wasn't available to us. As I mentioned in another comment, making the very
best decision you can given the constraints of your system is what one should
strive for. Not stopping at "good enough" because of (poor) intuition that
error conditions "probably won't happen".

We decided to go with LWT and eat the latency costs as a trade off to
"stronger" consistency, realizing that Cassandra doesn't offer the same strong
consistency as an ACID database. Not perfect, but it fit within our SLA,
decreased the probability of encountering duplicate values, and if there was
an error, it was easier to detect and the user could be directed to try again,
vs having a completely silent error condition that would cause a small
percentage of our users tremendous amounts of trouble.

------
AdmiralAsshat
> So imagine my surprise when I showed up at my first day on the job at a
> startup and found no tests at all. No tests in the frontend. No tests in the
> backend. Just, no tests.

That one hits home. I felt like I was being so _helpful_ when I, fresh-eyed
after finishing some entry-level C language book, suggested that we should
implement unit tests to the legacy software.

The product lead, to his credit, did not chew me out, but stated very
reasonably, "This software is old, relatively stable, and will likely be dead
or sunset in five years. It's not worth the man-hours it would take to try
retrofitting unit tests onto a piece of software this old, only for the
product to be killed six months after we finish writing them."

~~~
mevile
Tests are a really important part of development. There's nothing wrong with
suggesting tests. The wrong thing is to insist on it to the point it creates a
conflict with you and your team. Either set an example and write tests and see
if it creates value and your team is OK with it, make a convincing argument or
if you think tests are needed very badly because everything is broken all the
time and you can't convince anyone, get a new job. Sticking around and being
bitter about it is the thing that's bad.

I usually ask upfront in an interview if the team writes tests and if they
don't and I get the idea they don't want to I probably wouldn't work there.

------
asheikh
My Absolute truth I unlearned as a Senior developer. your knowledge, hard work
and quality of work is not important. The relationship that you have with your
boss and your bank account is what you need to focus on.

~~~
hiram112
> your knowledge, hard work and quality of work is not important.

Bingo. I used to be that guy who'd spend my weekends fixing the code that
everyone else left messed up on Friday or at the bookstore reading up on the
latest framework. And I thought that someday it would be recognized with
promotions or more pay or even a pat on the back.

Nope.

> The relationship that you have with your boss ...

I should have been the guy who was always socializing with management at the
office and happy hours. I should have been pushing my way into positions that
were closer to the money itself - like getting contracts, attending
conferences with management, architecture etc.

This is becoming even more apparent as I hit middle age, and it's harder to
justify my high salary when the majority of our code isn't really all that
complicated.

> and your bank account is what you need to focus on

But deep down I always knew this was true, so I lived frugally and saved most
of my money. I honestly don't see a great future for guys like me who enjoy
programming but are too introverted or just don't care to go into management
positions. There is simply too many H1Bs, foreign competition, etc to justify
high paid developers in most companies that aren't doing Google type
development.

------
redleggedfrog
What a great article.

Definitely goes under the heading of "Truths So True They Seem Obvious."

As for "Disorganized or messy code isn’t the same as technical debt," I can't
look at messy code without automatically cleaning it up. It's automatic as I
read and understand. In the last 5 years I've probably checked in hundreds of
PR's of cleanup. If this takes anymore time and/or effort on my part I don't
notice it. The only thing is someone has to merge it.

~~~
hashhar
I have a rule of thumb to assist with this. If i feel like I have to maintain
some state in my mind to understand a particular piece of code then I opt to
clean it up since it'll potentially save future developers that time.

~~~
yomly
The thing is, especially with juniors, cleaning up code leads to a few things:

\- poorly executed cleanup (aka regressions)

\- misunderstanding of requirements (new bugs)

\- "standardization" of naming (now you have two standards
[https://xkcd.com/927/](https://xkcd.com/927/))

\- restructuring of code/renaming of abstractions which then adds friction to
original authors of code (provided they are still around)

Left unchecked this can all happen, at the expense of feature work, and an
unmerged PR resulting in missed deadlines and a frustrated junior. Alas we
usually learn best by making mistakes though and I find this one hard to teach
for some juniors.

I would argue that a measured tolerance of ugly code (and sometimes bad code)
is more important until you learn how to spot and write code that doesn't look
wrong.

Two articles I found helpful:

[https://www.joelonsoftware.com/2005/05/11/making-wrong-
code-...](https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-
wrong/)

[https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

~~~
AnimalMuppet
I read once someone's estimate that the probability of introducing a bug when
fixing a bug is somewhere between 20 and 50 percent. That probably also
applies if it's _not_ a bug - if you're just cleaning up something. That
should make you think twice.

In particular, it might make you think about game theory. Is the expectation
value of this change _more_ bugs, or _less_? Will making this change have at
least a 50% chance of preventing a future bug?

------
jeremycw
As a Junior: Creating the most abstract grand architecture to apply to every
facet of my application will solve all my problems.

As a Senior: Replacing all this architecture astronaut indirection with simple
linear concrete code will solve all my problems.

------
edw519
Excellent article! Thank you, Monica. You just put into words a whole bunch of
stuff that I always "sensed" but never "said".

After spending 7 million years (it sure seems like it) cleaning up the most
vile garbage code you could possibly imagine, I'd like to elaborate on this:

 _Architecture is more important than nitpicking. While a small line of code
could be improved, the stuff that tends to cause bigger problems down the line
are usually architectural. I should’ve focused more on the structure of the
application than tiny bits of code early on._

Architecture = the sum of all those seemingly unimportant "tiny bits of code".

It seems like every time I have to refactor or (heaven forbid) rewrite, I have
to start deep down in those tiny bits. I've worked places with all these
"genius" architects, but when I dive deep down into the code, I find a sewer
than couldn't possibly support software life as we know it, no matter how
brilliantly it was conceived.

Fellow programmers, you probably know exactly what I'm talking about, all
those cancerous tiny bits that kill even the strongest patients:

    
    
      - variables so horribly named that no one could ever interpret them
      - 800 line iterations surely destined to be broken by a maintenance programmer
      - conditionals so illogical that no one can tell if they ever worked
      - early exits to hell that can only be fixed by rewriting
      - double negative logic that could not never fail to break
      - 8 lines of code where 1 could do
      - <add your own>
    

Great architecture comes from both directions, "above" and "below". From my
experience (unlearned as a junior developer :-) ), 90% of the problems have
always seemed to come from below.

Get good at the trees and the forest will flourish.

~~~
reymus
> \- early exits to hell that can only be fixed by rewriting What do you mean
> by that?

~~~
jiveturkey

      if (a) {
        do_something();
        return;
      } else if (b) {
        do_something();
        if (something_else() == -1) {
          return;
        }
      }
      
      do_other_things();
      
      maybe_exit_here();
      
      maybe_keep_going();
    

it has similarity to frequent `goto label` type of coding

~~~
desc
I'd argue that this sort of thing is fine, as long as the `return` is not
nested deeply. A function which starts with a list of 'early exit' simple
conditions is fairly easy to deal with, compared with one where you need to
read the _whole thing_ to check that the value assigned to the returned
variable isn't reassigned later in a different condition. Early returns can
significantly reduce cognitive load if used correctly precisely because they
exit directly.

Once you have complex bail-out scenarios, the function needs breaking up or
insanity follows... but that's true of any sufficiently confusing decision
tree.

Generally I have found `else` to be something of an antipattern. I usually
find it cleaner to write the code as 'this special early bail-out with a
return, and the other case is just the rest of the function'. A bit like
pattern-matching in Haskell, or a `switch` block in which the default case is
the usual one. I also try to avoid reassigning variables, eg. in Typescript
everything would be `const`.

But like all generalities, these have exceptions!

------
alexhutcheson
Multiple of these points could be grouped under the general belief that
"Everything is equally important". The #1 change required for growing into a
senior role is to form a habit of ruthless prioritization of how you spend
your time (and your team's time, if applicable).

Often you end up in situations where all of the following are true:

1\. Your teammate or colleague is designing or implementing something.

2\. You have different ideas about how that thing should be done.

3\. Your ideas would produce an objectively better system.

4\. Even though (3) is true, the improvement to the system or design isn't
worth the cost in your time, team velocity, team morale/development, etc.

In that case, the right move is not to intervene, and to let your teammate
design/implement the system their way. This is hard to do, because most
engineers are natural maximizers[1], but for most tasks you're much better off
with a satisficing[2] approach. This isn't to say that you should never give
feedback on designs or in code reviews - you absolutely should, but always
remember that you have a limited budget for your own time and for team morale,
and you should spend that budget on the feedback where it will make the
biggest difference.

[1]
[https://en.wikipedia.org/wiki/Maximization_(psychology)](https://en.wikipedia.org/wiki/Maximization_\(psychology\))

[2]
[https://en.wikipedia.org/wiki/Satisficing](https://en.wikipedia.org/wiki/Satisficing)

~~~
bmon
This really hits home to me. I worked on a project where I encountered an
almost identical situation to the one you described. I stuck my foot down, and
insisted we build the objectively better solution. We did, and only much later
did I realise the damage I had done to my coworker's morale.

Looking back, I completely regret it. If I had my time again, I would stop
after explaining the alternate solution. The time we would have had to spend
fixing the problems with the original approach would have been worth it.

I've heard this repeated a lot, but I'm really only just starting to
understand: Often the best leaders speak up less, rather than more.

------
arvinsim
> I also learned that job titles don’t “make” you anything. It’s kind of like,
> being a CTO with a 5-person team is different than with a 50-person team or
> a 500-person team. The job and skills required are totally different, even
> if the title is identical. So just because I had a “senior” job title did
> not make me a senior engineer at all. Furthermore, hierarchical titles are
> inherently flawed, and difficult to compare cross-company. I learned it’s
> important not to fixate on titles, or use them as a form of external
> validation.

Unfortunately, they do matter in the real world.

~~~
dullgiulio
Well, depends. I know people going from CTO of a small start-up to individual
contributor in a bigger company, probably for money.

Titles count a lot inside an organisation, thought.

~~~
mariefred
I used to work with one of those, he traded his title and pay for a work
permit in another country

------
iamleppert
> "Good enough is good enough"

+1000 to this. Please don't be the guy that slows me down and prevents me from
delivering features because you insist on everything being perfect. I can't
tell you how many times and how much money people who are obsessed with code
quality waste. They spend months polishing code only to get out a feature that
no one uses and doesn't matter. But hey, the code is "perfect"!

~~~
illvm
Who defines what "good enough" means? Is it basic functionality? What if that
basic functionality contains security vulnerabilities? What if it is written
in such a way that will cause potential, foreseeable problems down the road?
What if it is written in such a way that it is only understandable to the
author? What exactly is "good enough?"

~~~
iamleppert
I’ve found it’s far better to error on the side of speed and work
pragmatically on features rather than trying to deliver perfection. That’s
just me though. Nothing is going to be free of defect or perfectly secure.

------
SamuelAdams
> Documentation lies

This is a very true statement, especially concerning legacy codebases. I have
worked on some projects that have had several developers make changes to it.

The original developers were great: they commented every class, had comments
for all the methods, and added comments for any complex or funky logic.

Then the changes came. And the next developers hacked and slashed the existing
code base to meet the new spec. Except they did not update any of the
comments, so now what was once true and reliable is now frail and
questionable.

Now, whenever I inherit legacy code riddled with comments, the first thing I
do is delete all the comments. This helps me focus on what the code is
actually doing, rather than what someone thrice-removed said it should be
doing.

~~~
cuddlecake
I was thinking about this and because of the book _Clean Code_ I had already
decided that comments will lie at some point.

So I moved towards descriptive variable and function names, but those could
lie as well.

So I'm thinking, how could we ensure truthful intentions at all?

And I think only a combination of small pull requests, good variable and
function names and a thorough review can save us here.

But I don't know, I'm just a junior developer.

~~~
oalessandr
Types can help. Your code simply won't compile if the types are wrong.

The catch is that you have to define way more types, but if the code is
complex enough it's really worth it.

------
harel
I've been programming professionally for well over 20 years (and many years
prior as a hobby), and held "senior" to "C-level" positions. in my eyes I'm
still a junior kid learning new stuff all the time. When I stop seeing myself
as that, I'll switch vocation.

------
lukejduncan
"Loads of companies and startups have little or no tests" which should scare
you, or at least it would scare me if I joined a team.

You can definitely over test, but how can you possibly know what you built
works (or still works when you change it for the 50th time) if you have no
tests? There's a trade-off with testing. Early in the dev cycle, not testing
can make you go super fast (supposedly, this hasn't been my personal
experience but in general it seems to be true for teams). But you'll plateau
quickly and then at iteration 1+n you'll just come to a screeching halt
because you introduce bugs or the new engineer isn't confident that they
didn't break downstream things and needs to manually test everything. Testing
early will cause you to go slower earlier (again, not my personal experience
but seems to be generally true of teams) but you'll be significantly faster at
iteration 1+n.

I usually summarize this as: testing early will on average make your
development faster over the life of your codebase. Knowing this you can make
trade-offs. Not testing early is probably better called prototyping. It's OK
to prototype in production if you need to. But know what you're getting
yourself into.

~~~
jayd16
Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making
changes. Sometimes you want that friction but in a frenetic prototyping phase
its detrimental. This is especially true when business goals are changing
constantly (such as early prototyping).

How do you know what you built works? The only thing that truly matters is
that the user story is satisfied and to that end unit tests are terrible. At
best you could make some integration tests but that is not the same thing.

I also think there are better practices than tests to keep iteration pain low
but that doesn't preclude tests so I guess that's not an argument against
them. That said I prefer to focus on making composable, low side effect code
than write more tests.

Personally I hate tests although I come from games where you need human QA
testers to test that your game feels fun anyway so I do admit that's a unique
situation.

~~~
ramraj07
I still struggle to understand the real benefit of unit tests; the most
intuitive tests that test real business logic that I've written always become
something like semi-integration tests. Pure unit tests that test a small
isolated function are almost never useful to catch bugs after they're written.
The only legitimate use for them has been that it's easier to understand the
purpose of the function and edge cases. At times it makes me think about edge
cases and identify bugs WHIlE writing the tests, but once they're written,
they're never useful unless someones actively trying to understand that exact
unit of code.

~~~
skybrian
For unit testing, I suggest starting with parsers, or any string-parsing code
you have. They tend to be nicely self-contained and have lots of edge cases
that you can test in a data-driven way, using a loop.

Even if you're just using a regular expression for parsing, it can be worth
moving the parsing code to its own function and testing it like a parser.

------
tombert
About two years ago, I didn't get a promotion to "senior engineer" that I
thought I was going to, and I had a huge temper-tantrum to my boss about it as
a result (I'm still surprised to this day that I didn't quit on the spot, to
be honest).

I was upset, because people that seemed to be contributing less and were less-
qualified (at least from my admittedly-biased perspective at the time) were
promoted to a higher level than me, and I got a fairly form-letter-esque
answer of "we don't have the budget to promote you this time".

The next cycle, they corrected it, and I was officially a "senior engineer" on
paper, and I realized how silly my hissy-fit had been. Sure, I guess having a
bit more money was nice, but it's not like it radically changed the quality of
my life, it's not like having a fancy title changed how people really saw me,
and I didn't even bother updating the title on LinkedIn.

I don't think I was "wrong" in what I said. I do think that I deserved the
promotion over someone else, but at the same time, I also tarnished a
relationship with my boss and coworkers, and I let it get me far more
depressed than it should have.

\-------

I guess if any "junior" engineers are reading this, try and remember that a
title is simply that: a title. They don't matter a lot, try to not get too
upset over them, and obsessing over something so nominal is a great way to
build up anxiety.

EDIT: Just a note, I absolutely think you should call out a company if you
feel like you're being taken for granted. I'm not advocating complacency, just
make sure that your hatred is directed to the right places and try to avoid
getting too depressed.

~~~
linuxftw
Nah, f that mess. If you find yourself in a place that promotes the weak
because it's a buddy system, it's not a place to work long-term. It means your
boss is in 'don't rock the boat mode' and that's going to hold you back long
term. Your boss should be fighting for promotions for their best workers and
enabling growth in responsibility as well.

~~~
tombert
Oh, in fairness to my boss, he _did_ make a strong effort in the next
promotion cycle to get me promoted, which in fairness was only 6 months later.

The issue was the they had a limited budget for promotions, and basically
limited it to one person per team. This, by itself wouldn't have bothered me
too much, since the person who deserved it most on my team (someone with more
experience than me, and was definitely under-leveled) _did_ get promoted that
cycle.

What upset me most was that a person on another team (with 1/3 of my
experience, with no increased education, and on a team that accomplished
nothing (not just my opinion, that team was disbanded a year later)) got
promoted to a level higher than me. My direct boss didn't have any control on
that team.

~~~
linuxftw
Yeah, that clears things up. I think every organization has those dead-weight
teams. As long as you put tons of points on your stories in Jira, you look
super busy and management gets to see your pretty charts.

------
exabrial
The #1 absolute truth I unlearned was: The solution to your problem is the
tech stack or framework you're not using. Everyone in this industry seems to
have tech wanderlust; using the latest and greatest and unproven is seen as
sexy.

* "Oh we could do that, but we're on python 2.7"

* "Oh we could do that, but we're using Java"

* "Oh we could do that, but we're using a relational database"

------
jasonlhy
1\. Code and communication are the most important. If you are writing
extremely bad code, you will be annoyed how much time you will need to go
though to find the bug. The more you do, the more you will not like to touch
the code even they are written by you. (I have seen someone with this
experience) Understanding what your teammates are doing is also important in
order to support each other and provide valued advices, in this case code is a
communication medium.

2\. To write good software, we cannot just be a coder, we need to understand
the business and the project management

3\. There are many seniors became senior because of their age not their
ability. I am not talking about using a particular tech, I am talking about
their mind. Many of them still think like junior even they are at a senior
position, the way they are working didn’t scale at all.

4\. Fundamentals is very important. [https://hackernoon.com/the-doctor-and-
the-scalpel-78656f508c...](https://hackernoon.com/the-doctor-and-the-
scalpel-78656f508c9a)

------
jmull
Great post. Lot's of good stuff.

Just to comment on one part at random:

Code reviews would be more useful if review feedback was categorized:

1\. is this a matter of personal style? 2\. is this a judgement call? 3\. is
this something that is just wrong and has to be fixed? 4\. is this in-scope or
actually a separate issue?

(This is off the top of my head, so this is more of an example of the kind of
categorization I'm talking about than a proposal.)

It's useful because it helps to set the direction and expectations on what to
do about an item of feedback.

E.g. if you have a lot of 1. then the right "fix" might be to spin off a task
to develop a common style-guide. (Or maybe fix an out-of-date a style guide,
or to enforce an existing style-guide so that these issues don't dominate code
reviews, etc.). For 4. the resolution would be to open a ticket (or whatever
the process is so it gets proper consideration, prioritization, etc.)

Where I am currently we spend a lot of effort figuring out what to do about
review feedback (and I think we too often make non-optimal decisions which
sucks time as well).

~~~
DubiousPusher
The last couple of teams I've been on have had the custom of prefixing any
issue that is purely stylistic in nature with 'nit:'.

------
jasonhansel
I think another truth to unlearn is "users know what they want, and can
express what they want in precise technical terms."

~~~
cuddlecake
And the complementary truth would be "I know what the user wants".

My team and I are kind of trying to break this up, since we suffer from this a
lot.

------
scriptkiddy
I don't know if I can call myself a senior. (none of the companies I've worked
for have used senior/junior in their job titles), but one of the most
important pieces of information I've picked up is this:

The Simplest way is usually the right way.

What I mean is that fancy algorithms, sweeping design patterns, and "clever"
pieces of code are generally not the best approach to 99% of coding specific
problems.

Example: Nested for-loops. Generally a bad choice. When encountering a nested
for-loop, one may be tempted to try and refactor it into some sort of
recursive and highly-performant function with O(n) complexity, etc. You go
through all that work and then realize that the most iterations that for loop
will ever see is ~10. You just wasted a ton of time writing code that is more
complex, harder to debug, and generally more opaque.

In my experience, I've seen this a lot in the context of premature
optimization. I've also been the perpetrator many times as well.

~~~
jehna1
Premature optimization comes in many forms, and at least these three cases are
doing more harm than good:

1: "It's good practice"

For example: Wrapping every function implementation in a memoize function may
seem like a good idea (= it prevents doing unnecessary work-heavy stuff), but
it actually makes code both harder to read (more boilerplate to skip when
reading) and most cases slower (= even when a function is executed only once,
you're doing extra checks and function call).

2\. "We're gonna need this soon"

For example: many times I've implemented an abstraction that makes sense for
sharing code with a feature that I know we'll be implementing soon, only to
find out priorities have changed and that other feature never gets
implemented. What's left is an unnecessary abstraction that only makes the
code harder to read and maintain.

3: Optimising for speed/lines of code

Unless you're building a game engine, it rarely makes bang for the buck to
optimise for speed until you have identified an actual bottleneck in
performance.

Same for one-liners. It may be cool that you know how to write 10-line
function as one-liner nested ternary, but your "clever" code is probably less
readable and harder to maintain.

------
juanbyrge
One thing I learned as a developer for 12+ years is that the title is
meaningless and where I work, many of the highest impact developers would be
considered 'junior' developers. I wonder why people have such an infatuation
with the title 'junior' and 'senior'. Seems to be more prevalent in European
countries.

------
rb808
One thing the OP mentioned but I think isn't talked about much is that for me
everyone has their own style. Some people have great abstractions, others lots
of tests, some more code comments, interesting variable name choices, some
like functional-style, or lots of frameworks & patterns etc. From our team I
can often see who wrote something just from how its written.

Now as a junior I just wrote how I liked and hated everyone else's code. Then
came a long awkward phase where I tried to fit in closely with other people's
styles and figure out their intent and design - this is a very difficult way
to write code and I wasn't very productive. I thought about this a lot and now
I just go ahead and blaze a trail and other people can just figure out my
style. Move fast and break things - or being reckless, its often hard to tell,
but you wont be a 10x dev by trying to be nice and fit it.

~~~
ltc5505
Interestingly, I'm at that unproductive phase right now. On one hand, I could
fix this fast and ugly, but then my code is going to look no different then
all the code I go home and complain about. On the other hand, I can try to
make my code really nice and abstracted with well thought out design patterns
like <golden-coworker>'s. So, on one hand I'm a hypocrite and on the other
hand I'm slow and hardly productive because I am just learning design patterns
and no matter how many times I refactor my code it never looks as good as
<golden-coworkers>'s. How did you get out of this stage? Please help.

~~~
mceachen
This is surely debatable, but the best code is readable by Engineers of
Tomorrow with the least amount of effort.

Getting code reviews from other people that understand this, or pair
programming with them, is the best way to practice empathy for those future
code readers (which very well may be you).

Don't focus on commenting about _how_. They can read the code for that, and
those comments almost always drift from truth. Instead, focus on writing code
and comments that describe the _why_. Consider describing what other
approaches you tried, why you didn't use them, and why you went with the
current implementation.

This especially applies if your solution may not be the obvious first answer.

Try to help the Engineers of Tomorrow from repeating prior mistakes. Free them
up to make new and grander mistakes, instead.

~~~
rb808
I think that is nice, but may not be aligned with what the company wants. If
<golden coworker> is respected, well paid and promoted then by all means try
to emulate them. if <golden coworker> is gold plating a lot of small projects
that dont really help the business, and hackers are getting rewarded for
delivering new functionality that the bosses want, then that route is better.

------
tmaly
I believe more in tests and documentation now more than ever.

When you have to support legacy code with no docs, no specs, no tests, you
change your mind pretty about the value of tests and a good specification.

As a senior engineering manager, I push hard to get good requirements for my
team. Its being a sales person with the business side.

------
typon
One thing I would say about the whole "good enough is good enough" mentality
is that if everyone has that mentality in a company, your code quality will
decline so far that it will be impossible to get anything done in the future.
This has happened to my company because ten years ago people had this
mentality and it did work for them, getting us a lot of market share and short
term success due to high profit margin. However, today we are suffering
immensely due to those decisions, losing customers and new hires because no
one can get anything done except put out fires due to critical customer
issues.

I think a healthy mix of idealists and realists is necessary.. With senior
developers representing a good majority of the former.

~~~
templ123213
I think she covered that by mentioning that architecture is more important as
a senior developer. My understanding as a senior developer by what she means
is not to focus on optimizing the hell out of code. Too often, people would
demand others use the most optimize piece of code, but if the code is only
going to be called once or twice, you should focus your time on other things
more important.

I think your company is suffering from bad architecture design more than
anything else. It seems like everything is tightly coupled with little room
for modifications. This probably means those senior developers weren't really
senior to begin with. This tends to happen at startups where business is
prioritized and people get hired with inflated titles. I have seen that happen
in a lot of startups.

~~~
typon
What happened here was different. This is a top 25 Silicon Valley company,
thousands of employees.. But with poor software habits. The people who
designed the architecture were always under tight time constraints from upper
management, so they always accepted the good enough approach.

But you are right! The company is suffering from horrible architecture.. And
any attempts to change it are near impossible because of the sheer amount of
code and processes that we have. It seems like a never ending battle

------
airnomad
Developers are new factory workers. Pay is good now because industry is
expanding and there's not enough of us but it won't be like that forever. And
bottom line work is already being commoditized (WordPress ecosystem etc).

~~~
bluejellybean
From a hiring perspective, the problem is, and will continue to be, the
quality of each worker. Although there are a handful of similarities between
how the two professions operate, I think that it is unwise to make the factory
worker connotation.

The entire idea of a factory worker is that they can be swapped in place by
another and the output is maintained to a great extent. This just simply isn't
the case in software or really any creative work. Even if we assume two
workers have equal skill sets, something that is already dubious due to the
importance of cross-domain knowledge in software, the personality one brings
to a team will ultimately alter the entire team, sometimes good, sometimes not
so. The social dynamic within groups is a critical element and something that
cannot be commoditized away like other professions.

As to the point on commoditization within old tech, I can only answer with a
"well duh, It's tech!". The goalposts are always moving within this
profession. There used to be a whole heck of a lot of jobs in programming
super low-level tasks, those are largely gone and have been replaced with new
positions. Last year everyone worked on web apps, this year everyone was on
mobile apps, next year it's anybody's guess.

~~~
airnomad
That's because our tools are not good enough so what we lack in tools we
compensate by individual developer quality.

I spend a lot of time within WordPress ecosystem and I've seen people coming
to me with 20K products shops they've built and maintain without a single line
of code written.

I've seen companies operating online without having any developments either on
contract or in house.

Because for certain simpler scenarios, there's UI based tools you can run your
business on.

Sure they come to me because eventually they need something they can't do with
tools they use but those are becoming more and more high level jobs.

Web development is pretty much figured out problem. You have legions of
repleacable low value developers churning out pages and you have subset of
highly paid specialists who can do more advanced things.

But those gazillions web pages are doing their job, they drive sales,
improving information quality etc. so I could say digital workers are factory
workers of our time.

On certain jobs line is blurry - designers can do basic WordPress but they
also can set up MailChimp because machine needs to be humming.

~~~
bluejellybean
Perhaps we are arguing different things. If by developer you are referring
specifically to a web-developer, sure they are akin to the a factory worker in
that they are, by in large, on the way out. I am arguing the more broad sense
of developer as being a substitute for computer programmer.

------
ademup
My junior thought: spending 3 days to optimize code to make the UI faster and
use fewer resources will be appreciated by managers and users, so win-win.

My senior thought: spend 1 day to SOLVE the problem, and 5 minutes removing
the code entirely.

------
m0zg
Interestingly, some of these absolute truths are absolutely true at larger
(50+ devs, or so) companies because forward progress can't be made otherwise.
System not documented? Might as well not exist at all. Code is not tested?
Well, then nobody really knows if it works or not after even the most
insignificant and peripheral changes. People don't treat code quality as a
priority? Welcome to days/weeks/months of yak shaving to fix even the simplest
issues. Good at communication but can't code worth a damn? Consider becoming a
manager, not a "senior developer".

------
xupybd
No offence to other developers but this is the easiest read of any article
I’ve ever read by a developer. I wish I could write like that. I also wish
documentation was written by people with that talent.

------
rq1
What I learned as developper and Data Scientist is: either you know what
you’re doing and can see the big picture, either you’re walking blindly to a
“good enough” solution.

In the first case, I spend most of my time in architectural design and
modelization. The implementation phase is rather quick, because everything is
well defined and you can write a lot of tests upfront.

In the second case, you’ll discover the big picture by facing the problems
while trying to find and implement a working solution.

While getting experienced means how fast can you figure out the big picture.

------
jpswade
I think much of this depends what you are employed to do.

Sometimes it's about making things less complex, which means good practices,
code quality, clean code and testing means you can afford a bit more risk.

Equally, sometimes you employed to just get things done, make it work, even
fake it till you make it, proof of concepts, minimum viable products, etc.

I've done both, I enjoy both, but they are two different modes of working.

Ultimately the answer is "it depends" and milage may vary.

Quality is a journey not a destination.

Yes, put delivering value above anything else, sometimes that value is
quality.

------
vowelless
Great article. Related to the “code quality” point, what I have personally
realized is that it’s easy to over complicate solutions. Often, a simple
solution is better (especially when it is part of a larger, more complex
system).

When I was younger, I liked clever solutions to show off my skills. Now I
cringe at that. Other people have to read my code. And more importantly, “I”
have to read my code tomorrow or next week. I’ve started to really prioritize
simplicity. Which is ironically quite hard!

------
macspoofing
Good writup.

>Imagine 50+ comments on your PR with all the semicolons you missed!

Depends. You should have a style guide and it should document what the
expectation is. If it was decided that semicolons are mandatory, then code
review should be failed. If they are optional than the code reviewer shouldn't
flag it. The alternative is to use a linter/formatter and either auto-fail
during a pull-request or have the tool fix it up.

------
perfunctory
> So imagine my surprise when I showed up at my first day on the job at a
> startup and found no tests at all. No tests in the frontend. No tests in the
> backend. Just, no tests. > Nada. Zip. Null. Undefined. NaN tests.

On my current project I have 100% test code coverage. Which I believe is quite
unusual. But I am pretty sure that if I give a talk about how I did it, most
people will be horrified.

~~~
kraftman
Why would people be horrified?

~~~
perfunctory
Because it doesn't follow the best practices.

------
z5h
Thoughtful and deserving of HN front page attention.

------
yters
I disagree with the documentation one. I really think developers need to focus
a whole lot more on documentation, possibly prioritizing it over code.

In fact, I think there should be something like a documentation driven
development, where first devs change the description of what code should do,
and then change or add the tests, and then finally write the code.

------
templ123213
I agree. Title doesn't matter. There is so much title inflation in the
industry today.

For me, becoming a senior developer has allowed me to see code more
objectively than before. Instead of following convention to the T, I can now
look at code and make my own judgement whether to follow the convention. It's
great to have the sense of relieve.

------
seomis
Over the course of my career, I've gone from deploying via scp, to svn-up/git-
pull, to every variety of actual deployment pipeline imaginable with dedicated
dev-ops teams. Now I'm the only engineer at a tiny 501(c)(3), git-pull
straight from production again, and have never felt more free.

------
cdevs
I love the uncluttered ui for the site you work for
[https://sumup.com/](https://sumup.com/) sticks the message to the potential
customer instead of shoving lots of blog/jobs/other links all over the place
as in the top menu.

------
wanttocommentt
good article, I agree with most of the things. However code reviews that only
have comments about code style are kinda useless in my opinion. I rather get
50 comments about how to improve my code instead of missed formatting. (which
can be also done automatically)

~~~
celestialjeu
That is the exact point the article is making. When you are junior you think
that code style is the most important thing but it isn't. (Also it can be
handled automatically as you say)

------
james_s_tayler
> "Not everyone will become senior during their career"

This. So much this. I didn't realise that until a little while ago but when I
did it made me realise I need to understand actually what make someone a
senior. It's not just an automatic progression.

------
cm2187
Absolute truths passed on by my various line managers:

\- Assumptions are the mother of all fuckups.

\- The optimal number of people in an organisation is 3. At 4 you start losing
efficiency. At 80,000....

\- The more you progress in the hierarchy, the more you realise it is the same
idiots at every level.

------
gastlee_za
We’re so far behind everyone else (AKA “tech FOMO”)

This one hit strongly for me because I didn't realize it until reading this...

I am sure our CTO and PM are tired of me pushing for the latest tech I read
about on here all the time. I will hold back a little more from now on.

------
saagarjha
> I read “that orange website” all the damn time.

Yeah, don’t take the “orange website” too seriously.

~~~
draw_down
Unless people are saying nice things to you on the orange website, then you
definitely should listen!

~~~
saagarjha
I mean, it's often valuable to hear what people have to say about you, good or
bad, but you also need to figure out when the feedback you're getting is not
useful.

------
chasd00
A good plan violently executed now is better than a perfect plan executed next
week. - Patton

It's much better to get something, anything, on the screen and working than an
elegant design constantly refined but never put to actual use.

~~~
parasubvert
Not just "anything". Patton did say a "good" plan. A bad plan can tank you
just as much as elegant design that isn't used.

------
mooreds
"It's about the code." That is probably the biggest untruth I though when I
was a new developer (I dislike the term "junior").

The truth: "It's not about the code, it's about the people."

------
himynameisdom
i think now more than ever, there needs to be a bridge mindset between
technical and non-technical. i learned that very early on, and even spent some
time in a customer-facing, non-technical role to hone my bridge mindset. the
ability to have empathy for the end user, and everyone else upstream who will
touch your logic, is paramount and takes care of a lot of issues.

it's up to us as technical professionals to care about both the "what" and the
"how". the ability to pan in and out on a particular need was learned early on
and i cannot be more thankful of that.

~~~
busterarm
Some of us technical people like to be client-facing. The key is to make room
for us to do that. Let us handle the client/user and then take meetings with
us so we can filter what's appropriate to you.

The biggest problem with "technical people" is the desire to retreat to a pair
of headphones and not communicate with anyone all day. Set aside some
consistent portion of your day where that's the only time you'll take meetings
and we'll work around your schedule.

~~~
himynameisdom
I agree. I enjoy speaking to prospects and clients, but I know not everyone
feels the same way. I would say instead of letting technical people handle the
client/user, it should be done in a collaborative way. Filtering shouldn't be
necessary as that has the potential of keeping possible problems/solutions in
the dark.

Technical and nontechnical people should collaborate face-to-face on a daily
basis. That includes customer interactions.

------
sytelus
As you get older, the thing you unlearn is that there are no absolute truths.

------
jonstewart
The only thing to do when you implement a linter is fix the 800 errors it
generates. It shouldn’t take long. That’s absolutely the right thing to do,
and I’d happily back anyone on my team who does that.

------
craftoman
How can you define seniors as pros? I know some senior devs that suck at
programming, still coding in Perl using Notepad++ and their systems are full
of bugs.

------
vortico
Perhaps the reason for "nobody writes tests" in the real-world isn't primarily
because of time/cost, but because virtually no real potential bugs are
testable. If you're writing a JPEG encoder or database model handler, yes, you
can test that all day, but those things already exist and are well-tested for
you. But if you're designing retail software or a web app, there are 2^10000
things that can go wrong, so most companies ignore automated unit testing in
favor of human quality control.

~~~
wan23
This is all wrong. When you have enough people working on a codebase such that
not everyone knows everything about it, tests are a great way to document the
behavior. They're much better than something like a wiki, in fact, because
nobody actually keeps that kind of documentation up to date.

~~~
vortico
I'm not arguing that tests are useless. I'm arguing that tests are usually
impossible. I invite you to suggest a test for
[https://github.com/VCVRack/Rack](https://github.com/VCVRack/Rack) for example
that could either 1) have prevented a bug, or 2) document the software's
behavior.

------
vonseel
> Early in your career, you can learn 10x more in a supportive team in 1 year,
> than coding on your own (or with minimal feedback) for 5 years.

Spot on!!!

------
kannanvijayan
I've been doing dev work for 20+ odd years now, and I suppose I can relate to
many of these realizations. A young developer's framework is full of sharp
polemics that soften over time as we scrape against them through experience.
It's definitely something I look for in junior devs - a few strongly held
opinions and a willingness to back them up by referring to some coherent
"moral" framework - as long as this does not descend into technical dogma or
dismissal of other perspectives.

If I were to step back and try to characterize the growth in my understanding
of software development in a single general statement, putting aside all the
hard-tack technical experience, it's this:

I am beginning to understand the subtle and complex delineation between _good_
and _useful_, and the role that execution plays in that - with all it's myriad
parts: prioritization, management, technical risk mitigation and hypothesis
validation, consensus building on technical direction, post-hoc validation,
etc. etc.

And usefulness has a lot of facets in execution: not just technical but
social. A good project and good idea might come to nothing if you are
oblivious to obtaining some organizational mandate for it, and it gets
sidelined due to shifts in priorities. If this happens, it means a misstep was
made earlier: either the project should never have been started at all - due
to awareness of upcoming priority changes, or you should have done the
organizational consensus building to ensure that the work had the runway it
needed to complete.

The same goes for technical consensus among implementors. Sometimes this can
be avoided by giving clear mandates to trusted individual leads, but come
complex projects really need the input of multiple senior members.

I'm starting to find lately that many of the contributions I'm most proud of
are the ones where I come to firm conclusions on what work _not_ to do:
concluding that certain tasks that were good but not useful enough, or
determining ahead of time that certain planned implementation paths are
actually not going to deliver what we might have expected them to, and thus we
should scrap that idea. It has saved inordinate amounts of time that would
_otherwise_ have been wasted.

The challenge for me has been reconciling this new understanding with my old
methods for evaluating my own performance. I know these days, within
reasonable bounds of arrogance, how to write decently complex software and
understand it. As I move on to considering these higher level concerns, I find
that I'm asking myself whether that opportunity cost is worth it: "I _could_
be spending time writing good code right now, instead of analysis and reports
and meetings and planning. Is this new activity of mine _useful_?"

I'm still building my internal model for measuring my effectiveness in this
new domain.. but it's clear that it's a profoundly impactful and worthwhile
multi-factor optimization problem to tackle.

------
jpfed
But seriously, put in your damn semicolons.

------
BentFranklin
A paean to normalization of variance.

------
wltprgm
Most of the time legacy code and technical debt appearing on same project

------
patsplat
Learned as a junior: results matter Learned as a senior: stories matter

------
icsllaf
>I read “that orange website” all the damn time.

Is she talking about HN?

~~~
class_struggle
Yes:
[https://twitter.com/monicalent/status/1137013118532558848](https://twitter.com/monicalent/status/1137013118532558848)

------
saurabhnanda
I must say this is a very well written blog post.

------
Kagerjay
I just started my first job as a junior-mid_level dev last week, my team is
really awesome and I've been learning a lot. I'm the only junior dev on a team
with 3 mid to senior devs, so there's lots to learn.

1: A great quote from one of the most senior developers I look up to town said
this: a developer who's been developing for 1 year can have _far_ more
experience than someone who's been doing it for 3 years. I find people who
introduce themselves as "developer for 15 years" aren't those types, rather
it's the ones that show innovation.

Another quote is this - to become a better developer, you need people at the
same level as you, more experienced, and less experienced. So I've taken it
upon myself to mentor junior developers in town. Other ways I've learned is by
talking about technical challenges from multiple developers in multiple
companies in my surrounding region, doing technical & lightning talks, and
participating in hackathons.

2: I wasn't entirely surprised by how little testing there was even at
companies that have been around for a 3+ years, I had learn that most
companies in my area (even the ones that have great developers) - code test
coverage was poor. There is an opportunity cost in testing something that
might change later. As kent dodds put it, do some tests coverage on core
features, but have integration tests

3: I think working with legacy codebases is a great way to learn. The codebase
shows a story about how the scope of the project changed, how workarounds were
made to meet client expectations in short turn around time, etc. These things
you don't learn on your own. Being forced to break something down and build it
into a better version is rewarding, so long as it's not everything you do.

4: My first code review was more informal, it was more pointing out everything
I didn't consider when implementing a feature. E.g deleting old unused code,
formatting things semantically and expressively, etc. Was still setting up my
dev env so there were a few grammatical errors that didn't match eslint
styleguides, but we had test runners for those.

5: Documentation to me has always been important, but forcing it upon others
as a way to bookmark something I avoided. I think it's far better to just
notate on a piece of paper your interpretation of how the code works, or write
your own documents in Confluence/team-wikis so your senior dev can understand
your interpretation of how things work. As the new dev on my team in a year,
documentation was out of date and each dev only knew specific parts of the
codebase, so I've been updating how everything works from a eagles-eye
perspective. Those notes have a lot of value to the next dev that gets hired,
because they come from a clean slate like yourself.

I also think, documentating your pseudo-code inside of tickets is important.
I've learned the hard way from getting fired at a previous job many years back
- you need to actively show your team what you do. Documentation is the lowest
hanging fruit, you need to think about what you're going to say in your daily
standup tomorrow, communication is essential

6: For me technical debt is really being able to identify where the debt lies.
For instance, rails and laravel has well documented magic, but the path less
traveled needs to be understood. My rule of thumb is if I'm going to write
less-than-ideal code, it needs a comment block indicating why I did so. Don't
push code you yourself don't want to read 6 months later

7: In regards to seniority, I think the best developers know they are junior
in other areas and are multidisciplined in other fields besides programming.
I've learned a lot of great wisdom from developers in my city's slack channel
just by seeing conversations unfold. I know some first year developers whom I
already consider senior, and some developers who've been doing this longer who
I do not.

I think the most important thing I've learned in these 2 weeks in my first dev
role, you can be a mediocre dev who just copypastes things and still be a
great asset to any team. There's a lot of value in just documentation &
communication alone

Other things I learned - you can bother your senior dev if they just sat-down
or stoodup from their desk, or if their headphones are off. But experiment
with communicating asynchronously in slack and synchronously in person and see
what works and what doesn't - even if they sit right next to you.

At the crux of everything, it's important to have a certain growth mindset. I
embrace a japanese methodology called LEAN. Other things - being okay with
self-humilation is a great way to learn. Other things - force yourself to take
breaks by only using small water bottles or none at all.

Also, make sure you say hello to everyone in the morning, my office is 20+
mechanical/electrical/civil engineers/designers, I make sure to say hi to
them. I take the longer-route of walking through the frontdoor every morning,
my boss makes fun of me for that. Give the gift of giving to others in the
community, it reflects well on yourself, my team already had heard of me
despite never meeting me b/c of how active I am in the local tech community.
Rubber duckies are good inexpensive programmer gifts.

------
kailuowang
Epoché

------
trpc
That's the kind of talk I always hear from mediocre devs once they reach their
first management job.

