A thread for Junior Developers/Engineers
twitter.com
twitter.com
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...
This actually epitomizes what I've found to be my biggest frustration as a developer: "it would be super helpful if, in addition to doing all the computer stuff, you could do all the other stuff as well so I could just not do anything but still get paid."
For me, I could write all the code that my entire team produces, but I am outmatched in the eyes and minds to turn things on operationally. That is, roll it all out and do investigations into problems.
So, my gut is that this trope is based on context. My context is as an infrastructure service provider. Thus, my big problem is operations.
I imagine if one does UI, then that is 80% people problem.
If the problem is science, then the problem is the code and the science.
I think what we are seeing is the "Pareto principle" played out in different arenas
I personally agree. The amount of good ideas and good software I see everyday, makes me wonder how the heck did people design and implement these beauties. I get depressed all the time since I am unable to conjure up such beautiful design and code for a problem. I think this is affecting me mentally. Does anyone have any advice for me?
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.
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 ¯\_(ツ)_/¯
Woes of the open office
Management occasionally suggests that maybe the meetings are a bit too long, but I think everyone is generally okay with saying they need the meeting to end because they want/need to work on something.
I'm now wondering if I need to make it a little more clear that that's a thing they can say without it causing an issue.
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.
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.
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.
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
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.
> 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.
I love this stance.
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.
Yes...but, only for really good engineers.
Figuring out how to design half of a system isn't anything. Anyone can do that. Non-programmers do that all the time. Engineering a solution means the whole thing, not just the easy parts of it, just like coding the solution means coding the whole things, not just the easy parts of it.
Edit: Hey, it is easy to implement code having bugs (shortly: implement bugs) and do many fixes further. It is hard to understand the problem and write code once, which won't need any bugfix. Think about the Apollo-11 code [0] - one tiny bug and astronauts might be dead.
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.
Exactly!
> By far the biggest mistake I see developers make is making their method/function bodies too long. Extract your methods people
As a general rule this is just one side of the coin imo. I often see this approach increasing the complexity of control flow in direct proportion to the simplification of individual code blocks. Net gain zero.
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.
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.