
A thread for Junior Developers/Engineers - yvonnick
https://twitter.com/jamesmh_dev/status/1080455811048984576
======
yakshaving_jgt
Generally I agree with this thread of advice, but I’m a little fed up with
people constantly asserting or implying that coding is the easy part, and
culture is the super hard part.

Get a grip. Coding is a challenge for junior developers. I see nothing
constructive in spreading this idea. Not only is it nonsense, it seems to
further the stereotype that programmers are all academically smart and
socially incompetent.

Edit: Please see Camille Fournier’s earlier take on this, as she says it
better than me:
[https://mobile.twitter.com/skamille/status/10047311365625610...](https://mobile.twitter.com/skamille/status/1004731136562561025)

~~~
oarabbus_
It also furthers the notion that "coding is easy" and if it doesn't come easy
to you then you simply aren't a good programmer and will never be one.

~~~
mesozoic
I think this really means that while coding is hard it is the fun thing, it is
a hard thing that is fun to do and easily can lead to flow states which we
interpret as "fun". That's great, as you advance in your career though it
turns out many times coding isn't the most valuable thing you can be doing
with your time but rather things like explaining, teaching, guiding. Things
that aren't so easily defined as fun. So coding is easy not as in the simple
vs difficult way but in the "easy going" way.

------
fisensee
> Maybe every morning they take the first 30 minutes of their day to tell you
> about what movie they watched last night? E-v-e-r-y-d-a-y.

Funnily enough I always think these are some of the best 30 minutes of my day.
Certainly beats having to talk about your favorite design pattern first thing
in the morning.

~~~
dtech
Yes, unless you're someone who wants to do something at that point in time.

I have a co-worker who gets fidgety for beers every Thursday around 15:00. He
starts walking around, loudly talking with anyone and telling stories. That's
super-annoying for me because 14:00-17:00 is the time I'm most productive.

Woes of an open office ¯\\_(ツ)_/¯

~~~
loco5niner
Same here. I used to get in at 6. 6-7 was the most productive hour of the day
because general staff got in at 7. But my co-worker always wanted to talk
right when we got in.

 _Woes of the open office_

------
mathgladiator
I am planning to write a site that helps people understand the career beyond
the code. I have five sections planned.

1\. Not Yet Engineer 2\. Junior Engineer 3\. Practitioner Engineer 4\. Senior
Engineer 5\. Principal Engineer

I intend to index my thoughts as a philosophy guide and playbook for
situations since that is what I tend to focus on in my one on ones with the
people that I mentor.

It's funny that as I have gotten older, I focus less on the 'what' and 'how'
and focus on people growth, and now my primary export is enabling people to
become effective senior engineers.

~~~
walshemj
You know that most companies don't have such nice technical hierarchies.

When I worked for BT back in the day there where effectively two grades for
non management "professional staff" going from mpg1 to mpg2 was brutal
approximately 20-30 in the SE division (50k FTE) every 18 months or so.

~~~
mathgladiator
True, but that doesn't mean the behaviors are not mutually exclusive.

For instance, there is a time in your life before you know how to code and
there is a time where you think you know how to code and then have to
interview. I call this "Not Yet Engineer".

There is then a time when you think you know how to code, but you lack
discipline to execute within a team framework and a business context. I call
this the "Junior Engineer" phase.

After Junior Engineer, you are useful and can build things. Once you have
discipline and have knowledge, then are a "Practitioner Engineer". This, for
many people, is a terminal state and some companies call this senior engineer.
However, I have seen many people go from inflated titles to Software Engineer
at Amazon.

Beyond Practitioner Engineer, the core aspect of being a "Senior Engineer" is
the ability to lead one or two teams to build.

Principal Engineers then talk at an organization level and think of things
beyond two teams. The focus here is on strategy rather than day to day
execution.

Sadly, most companies don't understand the need for a parallel power structure
to compete with management.

~~~
walshemj
That's all very well but I was arguably at "Practitioner" level at 23 in my
first job (which did have the sort of tracks you suggest)

I did look at continuing down that track to CE status (I was / am a junior
member of the mechanical engineers) but it wasn't worth it

And very few tech employers is going to support its development staff like say
a big consultancy will for its civil engineers.

BT did have its Msc but that was targeted at the Labs really - that's the Uk
version of Bell Labs BTW

------
sarcasmic
1\. Communicating clearly in 'business language' is essential when the junior
developer interfaces directly -- not through an intermediary -- with business
people and stakeholders. This tends to happen in heavily siloed BigCos,
especially in places where IT is just a business unit among many, much more so
than in SV or startups. But it's also a skill that one rarely has an
opportunity to use in isolation, away from the pressures of estimation,
project management, of implicit requirements-gathering by listening to
business units segue to different business problem, and sometimes of fudging
and obfuscation and make-believe falsehoods to soften the impact of reality.
These are complex dynamics usually played at the senior team lead level. Most
team leads know this, and don't subject junior engineers to this game with no
help.

2\. These sorts of high-level expectations tend to get peddled around a lot,
not the least bit because it's both noncontroversial advice and a desirable
baseline, but they aren't even always necessary. Often, the systems one will
work on already exist, they already don't conform to an idealized model
because of a series of fixes and mistakes made under pressure. These points
are a stand-in for saying you should design and code in a way that future
maintainers can make sense of what was written. Sometimes that's using
patterns and strategies that are well known, instead of a contrived variation.
Sometimes that's staying true to the existing design of the product and the
codebase, because tacked-on parts in a different style will increase
complexity of the whole.

3\. Interfacing in the design and mechanical sense, and achieving that design
consensus using interpersonal relations are really two separate skills, and
once again it's reasonable to expect that consensus to be set not solely by
junior staff between different business units. After all, interfaces and
system boundaries ought to have business significance -- not only because of
the implications of Conway's law, but also because interfaces and their
outputs are often the only orgwide-visible products of the business unit. They
must stand up to, or meet the challenge of future pressures such as planned
re-use and enhancements, some of which will conflict with the intentions
behind the original design.

------
Yhippa
> Get to know your problem so well that fixing the problem by writing code is
> the last resort

> This means having to problem-solve with business people and doctors, for
> example.

> It might mean having to learn more skills: marketing, product design,
> business planning, etc.

I like this point. In an enterprise there are multiple ways to solve a problem
without code.

------
drewmassey
“Get to know your problem so well that fixing it by writing code is a last
resort”

I love this stance.

------
CodeSheikh
If requirements are not clear, stop coding and start asking questions. If your
company track stories in JIRA then tag PM or anyone from the business who can
help you clarify the requirements. From my experience, PMs are not sure what
the exact requirements are. So asking them questions open up a channel of
back-and-forth discussion.

~~~
walshemj
"If your company track stories in JIRA" I think that's your problem right
there.

If your building a product or major feature and not a bugfix you should have a
proper version controlled design document or documents to work from and also a
lead or architect to get guidance from.

~~~
giancarlostoro
Right after Excel, JIRA is one of the most abused tools out there. I _wish_
specs were in version control, but we too use that "ticket per feature"
workflow at my job. I rather a Confluence page outlining what we want.

------
balls187
"Coding is the easy part"

Yes...but, only for really good engineers.

~~~
InclinedPlane
I've been reading other devs code for about two decades now. Universally all
the code I see is not quite up to the standards I have for "good code" though
some of it is better than others. Most devs give up on getting better writing
code too easily, or more importantly they focus on the wrong things. There is
always room for improvement no matter how good you are.

Focus on making your code clearer, not fancier or "faster". Don't prematurely
optimize your code by eye. Generally just being conscious of the major
performance no-nos to avoid and being able to use appropriate tools (like a
profiler) when and if you actually need to tune performance is all you need.
Instead concentrate on making your code highly readable, self-documenting plus
fully documented (the best of both worlds!), as well as composable and
maintainable and you'll be well set. Not just will you make other developers
happy and improve the code base overall (fewer bugs, easier modifications for
inevitable feature changes in the future) but you'll make your future self
happier when you have to come back to that code.

By far the biggest mistake I see developers make is making their
method/function bodies too long. Extract your methods people, it's not that
hard and it's a great habit to get into. It takes skill to get good at it but
a decently named small function makes code more readable and more reliable.
And getting into the habit of making little functions that just take a few
inputs, do stuff, and return a value makes your code way easier to unit test
as well.

~~~
badpun
> Extract your methods people, it's not that hard and it's a great habit to
> get into. It takes skill to get good at it but a decently named small
> function makes code more readable and more reliable.

For me it actually makes code less readable. It makes the system more complex
(because you've added extra function definitions and function calls) and just
jumping back-and-forth between those small function calls makes code harder to
read. I would much prefer to have a larger method that just does things in
order, and, for readability, have its body divided into sections, each in
isolated brackets (so that variables have local scope) and commented if
necessary.

~~~
zawazzi
I think all humans are bounded by 7+/-2 chunks of working memory which I think
correlates to upper bound of understandability. Personally I break up methods
where I see more than 5-7 unique params/variables/concepts. Also usually co-
locating related methods will help which is what OOP does.

------
giancarlostoro
On that note what are good books to develop communication skills? Are there
any that are specifically targeting tech business communication as well?

------
Zero1X
Don't think I am trying to diminish the importance of this post but Gerald
Weinberg has talked about all these concepts a long time ago in his books.
Sadlly, I discovered him (through DHH book recommendations) at a much later
stage in my career.Gerald Weinberg should be a required reading to all
software engineers.

------
Envision_Envi
It's difficult to handle by junior developer itself.

------
InclinedPlane
My one major criticism of this advice is that it significantly downplays the
importance of communicating clearly among technical people. It's tempting to
think this is "easy" but I've seen countless examples among top developers at
all sorts of prestigious corporations proving that it's anything but.

Some common mistakes I see people make:

Excess aggression, ego, and emotion. Check your ego, disconnect your self from
instances of your work whether it's your code, your proposals, or your ideas.
And be kind to others in criticisms, don't criticize (and especially not
denigrate) other people criticize their code or their actions. Instead of
saying "this is bad, why would you write this garbage?" say "here's a way to
do it that I think is better for X/Y/Z reasons". The work is just the work,
it's a collaborative effort to improve it. There should never be shouting or
hurt emotions when hashing out designs or doing code reviews, work towards
that goal.

Insufficient context. Make a habit of regularly summing up context in ongoing
discussions and injecting it into the thread (email, IM, meeting, what-have-
you). Do this explicitly when looping in new people to a discussion. The worst
thing is to be looped into some long email thread and having to follow through
the winding and convoluted discussion just to acquire context that could have
been summed up by someone in the know with a few sentences. Even worse is when
significant amounts of context are missing from the conversation because they
happened in person or in other media or happened in previous discussions.

Unspoken assumptions. Much like summing up context stating your assumptions is
critical to communicating effectively because it's so easy to assume that your
little bubble of understanding is universal but it rarely is. And unspoken
assumptions are one of the easiest ways for two people (or orgs) to be party
to the same discussion and come out of it with completely different
conclusions about what will happen next. And on that note, be clear when
you're asking anyone anything, whether it's a question or a deliverable.
Address them directly, use a question mark. You'd be shocked how often people
fail at this sort of thing, especially in large discussion threads. Don't just
leave pseudo-questions dangling, waiting for whoever is responsible to pick it
up. Be direct, if you don't know who the responsible party should be, ask,
maybe nobody knows and it needs to be determined/negotiated. If you know then
make sure. And, of course, be polite.

Not going on the evidence. A close cousin to riding on unspoken assumptions,
especially problematic in troubleshooting and debugging scenarios. Definitely
a common mistake I see all the time in CS graduates (who, ironically, aren't
very good scientists). Use the scientific method. Don't just make assumptions
and tell stories that are convenient or kinda sorta make sense to you. Don't
just "satisfice" by resting on the first semi-plausible answer you land on.
Dig in, find the truth. Start with a hypothesis (or several), acquire
evidence, figure out if you can for sure confirm or falsify your hypothesis
(and competing ones) through the evidence. Keep coming up with other things to
check that could provide additional evidence one way or the other, and
competing hypotheses as well. Keep going until you have a rock solid "case"
and can prove your theory. I have seen even very experienced developers screw
this up countless times. They come up with some vaguely plausible cause for a
problem and then spend way too much time operating as though it's true,
without validating it first. And then they waste a ton of time and effort
trying to "fix" the wrong thing. Just as often devs will put in a hacky
workaround for a defect which just papers over the underlying problem. Pursue
defects to their root cause, file bugs in your tracker to keep track of that
information and put fixing it on the radar of the team/org/management so at
least they are making a conscious choice if they choose not to fix it.

