> 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.
My only gripe with this is that I like to get in early in the mornings to get work done before everyone else comes in and the distractions start. There is one other person that comes in as early as I do, and he will occasionally come over and start a conversation and just won't stop. It doesn't matter if I'm wearing headphones or anything. He's a nice guy and I will sometimes go along with it, but other mornings when I have a lot to do it drives me crazy.
"So it says here in your performance review that your peers have consistently rated you as 'not being a team player'... what do you think we can do to improve upon this in the next evaluation period?"
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.
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.
We actually have an informal meeting in the mornings here. Nobody is required to attend or pay attention, and we generally talk about things in our lives like TV/games/etc or what we did over the weekend, and then move into what we're working on.
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. 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.
Are you saying that it's okay for junior developers to develop non-acceptable solutions? Because it's not okay in my book.
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.
I'm not saying it's ok, just that people often have more trouble with coding than finding a solution because bad solutions can be easy to find but hard to code.
I also disagree, coding is the easy part. When you are junior not everyone requires from you to be know-it-all person nor providing super-good quality code, especially in your first months of journey in the company codebase. However, almost anyone wants to notice a "fresh air" and a person who shares his/her commitment in various form starting from the day one.
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.
No, definitely not. I took that example to provide you a real life example of software which cannot be "fixed in production" what is very known type of fixing code these days. If you do understand the problem you really can bring that quality of code which does not need any bugfix during it's run-time. As I written in second sentence: almost nobody wants from you providing that quality of code starting at day one.
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.
> Focus on making your code clearer, not fancier or "faster".
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.
> 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.
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.
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.
"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.
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.
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.
I honestly don't know, and I am considering inventing a platform so that I can express how I get feedback. I am definitely interested in feedback, but I also want to create an income stream from it.
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.
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.
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.
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.
I definitely agree with this and want to add that coding _well_ is difficult for people of all experience levels, it's not something developers get nailed down their first couple years of working and then have forever. But producing excellent code that is easy to work with can help with the culture part. I've worked with very knowledgeable and experienced engineers that could crank out plenty of buggy and convoluted code that caused other people headaches. Writing clean and well designed code makes coworkers lives easier.
I would argue "hard" is relative and every job has aspects that are "hard" or "easy" depending on the individual. While I appreciate this thread seed, to point to either set and label it seems arbitrary.
> coding is the easy part, and culture is the super hard part.
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."
It is kind of annoying, but I have a different viewpoint for why code is actually a small part.
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?
keep in mind that beautiful code often a) isn't and b) took years of refinement to end up the way it is now. Don't fret if your first prototype isn't the prettiest thing on earth, Just keep refining it until it's acceptable for your purpose.
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.
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 fixin...
47 comments
[ 4.6 ms ] story [ 106 ms ] threadI love this stance.
> 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.
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.
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.
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.
[0]: https://github.com/chrislgarry/Apollo-11
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.
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.
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
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?
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 fixin...