Hah. The tricky part is that some people will learn, some won’t. Some people will look back and cherrypick only things that worked and call it experience.
At the end of the day, the question to ask is: who is responsible for the product? If the product owner/boss/ceo is okay with it, who are you to question it?
What I do is try to talk through the pros/cons of what the other person wants to do. I will try to challenge what they’re doing with data and/or ask them to show me their data. I am open to being wrong at any point in time (ie try not to come across as judgmental or saying it’s a bad thing). Also, if you’ve seen the same thing in the past, walk through what happened and what you think the worst case scenario is.
If your colleague is insecure/anti-social/not interested in learning, you don’t want to work w/ them. I’ve had my share of ‘cowboy’ coders that were ‘moving fast and breaking things’. That’s not sustainable. You need to try to do something about it and not just hopw they will learn their lesson. Huge difference between lack of experience and sloppiness.
One of the problems with going primarily on past experience (and I've seen this happen a few times) is that there are some people who have a skill of just sort of hanging around whilst other people do the work. They can talk your ear off about the work and all the things involved, but they just don't do anything and when really pushed to do things they come up with just terrible solutions. I know one guy whose sole contribution to the codebase was to run an auto-formatter on every single repository. Those type of people can be very disruptive.
While I think there is plenty of people not learning the pasts problems, I think it's unfair to say it's all laziness and way over complicated. Business solutions are hard, as they're designed by people through a game of telephone until you get to the engineer intended to make it. Maybe the company put the burden on a junior engineer to save money. Should they tell their boss they need to spend a couple months researching? Okay so the company hired a senior engineer, who has been using X tech for 15 years that has seen a large decline in usage. Senior builds product, but gets a better offer and leaves? Who now maintains this? Hiring for X tech is hard, you bring someone on to learn it but they kinda lied at how much they knew and since no one in your org knew much about it they passed through. Now they're making a mess of the beautiful architecture the senior laid out.
Stop blaming this all on junior programmers and javascript. That's just saying those damn kids and their lack of respect for their elders is what's causing it. Truth is this is a relatively young industry, that's being used in just about every single aspect of life, where the cost to make a change is minimal, where the ability to learn is one of the most accessible skills, where business demands change on a dime.
Stop your own arrogance and laziness in understanding the landscape and the people in it.
As an inexperienced engineer I did the same thing. My punishment for my hubris was to have bizdevs who felt the same way about us.
The weird thing is though, I still actively encourage new devs to make this mistake in certain circumstances. For one thing, telling them no isn't going to help, we have no shared context, and the math of their productivity versus mine works against me spending too much time convincing them.
If the problem has a logistical or bureaucratic component, once in a while the stars align and they manage to pull off something the department has been trying to do for years but always runs into a wall. Some people in an organization will assume something is true if they hear it from enough independent parties. I know if three people ask me the same question about a block of our code, I start looking at that code suspiciously. Clearly something is wrong with it. Sending the 5th guy to ask some IT guy or product manager he same question, especially in the way a new person tends to formulate questions, sometimes knocks the cobwebs off and the person decides to change their behavior or volunteer to do something they have resisted doing before.
A week of junior dev time for a 5% chance to clear out a bag of tech debt is a good investment IMO. And if it doesn't work they learn something about why things are the way they are.
I had a senior coworker who used to laugh and say "You're new here aren't you?" and I started giving him grief for doing it. Sometimes the new guy is the only one who can get things changed.
I dunno.. whenever I read ‘don’t do this in production’ I spend ages trying to really understand why - only when I feel I’ve got a real handle on what the pitfalls are would I go forward. I’ve done that ever since I started programming over 20 years ago and I still do it now. Sometimes it takes me longer to code a solution but I do feel I spend less time figuring out why stuff breaks.
It’s not just experience. It’s about hiring curious and diligent people.
Okay, here's my attempt to distill things a bit. Now, I'm not very old, but my time putzing about this field has taught me that there are two components to carrying on successfully: experience, and communication.
Right now I run a company where we do science. To do our science, we have to write a ton of code. Web stuff, server deployments, numerical analysis, machine learning, hardware description, USB drivers, data visualization, you name it. Over the years I've gotten pretty good at picking the right level of abstraction for the job, and it's served me very well. The key is to have foresight about your situation, and foresight only gets better with experience. When I see one of the less experienced engineers at work doing something dubious, it's usually very easy to steer them away from danger. That's the experience bit; somebody has to know better, and has to act on it.
But knowing better isn't enough. If you want your academic lab to use better coding practices, you knowing better and flatly telling them to change their ways will never work. You have to convince them that they want to do it. If you can't come up with an argument for the use of your other language, or design paradigm, or SCM software that is both factually solid and contextually relevant enough, then 9 times out of 10 you are probably not hitting on the right solution. That doesn't meant that your lab director who is refusing to change is correct in his refusal, but I'll bet you if you pitched upon a solution that was right for the situation, and put some thought into your explanation, you would get a much better reception. The same principle applies when you're pitching a new methodology out in non-academic land, it's just that more often than not both parties' expectations are already closer to being in alignment.
Why does it work? Because most people in these types of environments, such as academic coding circles, are really quite smart. If something is sensible and sufficiently low friction, they will probably go for it. So, no, bad scientific code doesn't beat 'best practices'. But a good solution beats a bad solution every.fucking.time. If you can't show people that it's a good solution, it's probably not the right thing to do. Even if your idea is the better one, if you haven't convinced the people who are going to have to deal with it of this fact, they won't understand it, they will misuse it, mess it up, screw up their research and they will blame the software engineer. And they'd be at least partially correct in doing so, because you only painted half the house.
I'd end by saying 'It's really not rocket science', but... it really might be. ;-)
No one is saying the experienced individuals cannot code. Based on OP's comment I am going to assume he/she is young based on my personal experience hearing these types of comments throughout my career. They stem from only knowing one way of approaching a task, to which they respond negatively to anything different, particularly if it is outdated. Instead they should seek to learn from the experienced individuals and understand why they are solving the problems in that particular manner.
A while back I worked with team that had just brought on some new developers. Some of the developers were eager and would learn with out human intervention. Others would require and ask for some mentoring.
Neither way of learning is right or wrong and I appreciated both groups but one thing I did remember was one guy that did exactly what you did and it was highly irritating as a project lead to see relatively random files (given whatever sprint we were on) that were considered stable to show up in the source control change list with out some consideration of discussion. I would have to waste time and look what change he made to see if it was ok.
Very true. There are devs that spent years of their careers changing magic numbers in code they never understood. I believe that a lot of comes down to attitude and eagerness to learn. Because some people maybe haven't even had the opportunity yet to think about data but would love to.
This is so spot on it hurts. At my last job, everyone was going about building things completely wrong, and to them it was completely normal! I found it very difficult to work with them because they didn't view me as their superior, so they weren't receptive to me teaching them anything, and whenever I would suggest an idea on a design, they wouldn't have any opinions because they didn't know any better.
They would often times ask me to explain why it should be done one way or another, and have me to it in a 30 minute meeting. In reality, it would take us reading a few volumes of computer science text books before they had enough knowledge to understand where I'm even coming from.
Yeah, I feel like this is my entire early career. Back when I was at the bottom of the totem pole. I would point out poor designs ahead of time and offer a solid simpler designs. Always on projects I was ether fully or partly coding.
I would try to get agreement on the people it would effect and nearly always rejected. Then everything I pointed out would go wrong but:
"This was completely unexpected"
"really interesting problem..."
At one point our ($100 million USD) security monitor product was down for a month until a customer noticed on our behalf and flipped out. Due to a several problems I had repeatedly pointed out (and fixing any one of them would of prevent it).
If I full sailed ahead then I would get alot of grudges. Culminating in "I found this bug and its your fault" (which was nearly always end up being because that very persons regression) or some other baseless attacks during meetings. It was tiring.
My managers always liked me however. shrug
In turns out almost every time my peers and betters actually never understood our discussions (but of course it would look bad if they actually asked questions). As my career went on I would start forcefully asking questions to confirm their understanding. And indeed this was nearly always the case. So I started making really nice layouts and explanations. And this got me a bit further. But if someone is missing years of required background you can't teach them in a realistic amount of time.
I am careful about who I work with now. I establish during interviews that your future team (or teammate) has the needed technical capacity for the problem set they have relative to their position. I think about the problem set the day before and discuss with them how they are solving it and it has saved me many a time. People are often critical of domain specific problems when given in an interview but I always start there and work my way down to the applicable fundamentals. The higher up they can answer the more senior. It also avoids the problem of asking out of scope questions/coding problems.
The structure (who is doing what, seniority, and how both are established) should always be crystal clear and changeable. Something to be aware of are non-formal structure in an org. Like a junior dev. on random team x has the CEO's ear. These are much harder to find and deal with. The worst problems an org can have IMO.
My job is exactly to fix code which was not understood by its creators. And this “I have no idea why, but it works” (until it doesn’t) is the main cause of most of the problems which I work on.
For example, at my current company the developer who introduced a “clever” navigation system didn’t know how HTML forms should be used, and why servers still allowed what they did. It worked. Now, 20+ years later that sole developer’s stupid decision, and lack of HTML best practices will cost my company a few million dollars (and by the way already cost probably a few million). A missing day of learning (and by the way a clear sign, that that developer should’ve never trusted with this task).
Senior developers learn this, and I’ve never seen that better developers would be satisfied and would say “yeah, I fixed it”, when they don’t understand the what and how completely, even when it’s not strictly necessary. They burned themselves enough times.
Ok I've had one experience with a guy that I guess thought he was a rockstar, in my opinion he was my level (from looking at the code, although he was much better than me at DevOps), but he did have one awful failing, he didn't want to figure out why something was the way it was and just decided to rewrite everything.
Also he thought I had done something using ElasticSearch because I was an ElasticSearch guy, instead of having learned ElasticSearch because I thought it was what was needed (and no amount of explaining this simple concept could penetrate)
While there are lots of examples out in the wild of people making a mess of things due to lack of experience, hastiness, and not thinking long term, there is a two way street there. Experienced developers sometimes apply too many rules and too rigidly to deliver elegant, well-performing, timely solutions. I see people abstracting and decoupling things, applying highly generalized pessimistic patterns, bickering about how to name things that probably shouldn't even exist, let alone have explicit names.
Experience is obviously good but people tend to get inflexible and dogmatic, too.
Touché! Both luckily and unfortunately, this incident was not on my team.
Even then, I find it increasingly hard to argue people out of the nonsense they pick up on blogs and conferences.
Especially for newer techniques that are not yet proven to be inefficient, such as using micro services in the wrong context, one has to resort to arguments by authority. Some junior and senior devs are not very susceptible to that.
For areas such as web development for user interfaces, or taking in enormous dependency trees with package managers, the problem is even worse. Here, an entire industry had standardised on suboptimal methods. One can argue that this is wrong, but there is no viable alternative.
In the latter case, guiding only one junior developer does not improve things. One has to educate the entire industry.
Well said. You will see very fast if a dev is experienced or not by looking at code organization and naming. Although I deal with experienced ones that just like to live in clutter. You can be both smart and stupid at the same time.
So, basically you are saying you want to be the less-experienced dev, but not work with them. I think the prevalence of this attitude is a key part of the problem.
Having been in the situation, all I can say is that sometimes you have to expect "shocking" gaps when working with inexperienced people at not let it throw you. It's part of being a teacher. You have to remain positive. If they're quick to learn it when you teach it to them, it's fine. This is learning on the job and it's expected.
That happened to me at Google for someone who didn't come in as a software engineer. I didn't handle it well and it's one of the things I most regret.
This is definitely true sometimes, but the “wrong” kind of experience can definitely hamper people.
I have a highly skilled senior developer with a desktop app development background who joined our web team, he’s excellent at many tasks but keeps getting tripped up when dealing with state. He logically knows how it works, but his muscle memory when programming is so used to being able to rely on state that it’s hard for him stop letting those concepts leak in and trip him up.
He’s still an amazing asset to the team, but in this case he does have some experience that’s hampering him in a new role.
I currently work at an org where the least experienced dev has over 10 years of experience. Management is fine knowing that we will say what's on our minds if we don't think something is being handled properly.
At the end of the day, the question to ask is: who is responsible for the product? If the product owner/boss/ceo is okay with it, who are you to question it?
What I do is try to talk through the pros/cons of what the other person wants to do. I will try to challenge what they’re doing with data and/or ask them to show me their data. I am open to being wrong at any point in time (ie try not to come across as judgmental or saying it’s a bad thing). Also, if you’ve seen the same thing in the past, walk through what happened and what you think the worst case scenario is.
If your colleague is insecure/anti-social/not interested in learning, you don’t want to work w/ them. I’ve had my share of ‘cowboy’ coders that were ‘moving fast and breaking things’. That’s not sustainable. You need to try to do something about it and not just hopw they will learn their lesson. Huge difference between lack of experience and sloppiness.
reply