You make a good point. The junior team members I'm thinking about felt they didn't have the authority and so didn't approach leadership with a plan. I'm not saying they should assume responsibilities without direction of leadership, but rather that they can follow step 1 in the article regardless of their level in the organization. Even a senior person must follow the direction of leadership, the difference is that the senior person knows that they can approach leadership with a plan.
Hello. Article author here. I agree, people should only follow good ideas. I didn't explicitly mention this in the article, but I believe that a person in a healthy work environment who genuinely follows the process of feedback as outlines will eventually turn their bad or mediocre ideas into good ideas as they integrate feedback, or else the leadership won't approve their change and the team will refuse to adopt the idea. After all, it's tough to get people to voluntarily adopt a bad idea.
Hello. Article author here. You can do this and it might be the appropriate approach in some situations, but you run the risk of degrading your reputation with management. Putting aside the personal risk, I tend to think of maintaining your reputation with your teammates as more important in the long run than accomplishing something or being right about any particular issue, since it preserves your ability to persuade them in the future.
Also I've found that if management is resistant to change they usually have good reasons, even if sometimes they can't or won't share them, so circumventing them can sometimes be counter-productive. Usually better to just be on the up-and-up.
Security can be a pretty significant cost to the business and if your teammates aren't concerned about it then that's a red flag that maybe you're in the wrong place.
But for the time being, yes, consider not. First, consider whether security on your team is a concern at all, for example you're working on an internal tool and you can trust your teammates not to go looking for buffer overflows.
Otherwise, the question I have is, why is there no process for dealing with security flaws? Whose responsibility is it to set up that process? Send your discovered flaw to that person and suggest that they set up such a process so that you can submit any future flaws, and then your obligation to the customer is done. If you burn your relationship with your teammates, you give up any chance of influencing them to improve their security practices in the future.
Hello, article author here. I admit that the title is a bit clickbaity, but I paid careful attention while writing to make sure that the title is 100% correct. At the end of the process your coworker will agree with you -- only it may be because you changed your mind, rather than your coworker.
You're basically spot on with my strategy in writing the article. I stole it from Extreme Ownership, an excellent book that uses a similar tactic. The authors begin each chapter telling a story wherein they made a serious mistake, but leads the reader through their logic in making the mistake such that the reader is thoroughly convinced that the mistake was the right thing to do. Then they reveal the mistake and boom! The reader learns. I found it to be a very effective way of teaching soft skills so I emulated it here.
I don't want to trick anyone into reading an article that doesn't have any value to them so if folks feel that the title was inaccurate I'm totally OK with the thread title being changed. But I would point out that it means a totally different thing now that no longer reflects what's in my article. :)
Hey there! Sorry you're having to deal with this. There's not necessarily one solution or any silver bullet, but there are many things you can try.
The biggest thing I can suggest is to raise your level of thinking from UX to the business metrics. By this I mean, rather than trying to optimize your product for "best UX", try to optimize it for "delivering most value to the customer." Creative people don't like to admit it, but sometimes the creatively optimal thing (good UX/good design/etc) doesn't always imply moving the needle of the business metrics. If you don't believe me, look at how much Amazon sells with their terrible UX. Ultimately the only thing that matters in a business is delivering value to the customer, and if the bad UX doesn't get in the way of that then you can sleep well knowing that your lead's bad UX decision didn't hurt anything.
I've found that thinking in these terms allows me to separate myself and let go of concerns like these. If the poor UX decisions of your manager are having a business impact then you can go find that data and put a dollar amount on it. For example, "I did some A/B tests and we got a 12% lower clickthrough rate with the button there." Your manager may not agree, but at least now you're talking about the customer, not about UX. If you can't produce that data then you still win because the business is unaffected by this mistake and you get to make your lead happy by doing it their way. Winning trust by doing bad UX is still winning trust.
Here's an example-by-story: I was once an engineer tasked with building an automated testing system. Automated tests are easy to understand and so everybody has opinions about how they should work. And so my system's design quickly got bogged down with folks giving the same sort of "i like it better that way" arguments that your lead is giving you. So, rather than engage with any of them, I picked a single battle in the design of my system, something that nobody could argue against, namely that tests should actually be test descriptions, so that the test system can work with declarative data and make decisions about the tests more easily. I showed how that would have a measurable impact on the business (having the test descriptions gives the test system flexibility so we can e.g. filter tests on the fly so that at desk testing times can be kept to a minimum, or easily move tests between BVT and Smoke, or whatever) which sidestepped all of those arguments.
If that doesn't float your boat, I like lostcolony's approach. One possible route of addressing it is to go through the hierarchy. As they mention it can be a tricky approach, you should avoid saying anything negative about your leads or explicitly asking anyone to change their behavior.
You could also try just having an earnest conversation with this person, expressing to them how their behavior makes you feel, and asking them what you should do to gain their trust and the ability to work autonomously. Try to make the conversation not about their behavior, but rather about what actions you can take. "What can I do to take more of these responsibilities on myself?" Then if you hold up your side of the deal, they're more likely to be accommodate you.
It may not be what want to hear, but getting someone else to change their behavior is one of the hardest things you may ever have to do in life and is often impossible. You might have to deal with the fact that this person will always do this. As lostcolony says, you can quit, but I see this as a last resort. You're just going to run into the same problems elsewhere, and it benefits you to learn to deal with the problems where you are.
Good luck!
Jorge
Edit: Looks like sizzle said exactly what I ended up saying but much shorter. And lostcolony's reply to sizzle brings up a good point: You have to present your case delicately, be careful not to make this person look bad, and if they don't respond to hard customer data, maybe it's time to find a team that does.
Hello, author of the article here. You're right, I did miss that important point, thanks for pointing it out. I've made some minor updates to the article to account for it. Thanks!
Hello there, author of the article here. You bring up a great point: This is a case in which the stakes are high and some things I said in the article don't apply.
In this case I would suggest that there should have been a lead or senior overseeing your coworker who was responsible for the quality of their code. This person should have already demonstrated good judgment in code quality, should have some people skill and backbone in dealing with folks who take code reviews personally and have the authority of the team to make the final decision on whether code gets integrated into your mainline branch.
If you're not that person then there's not much that you can do about a coworker's bad code other than push the team towards a stronger structure and process to protect it from bad code.
Hello there! Author of the article here. I love the point you've made. Often there are long term costs in e.g. technical debt.
I assumed in this article that the stakes are low (and they are more often than we think) but I have a future article in mind about how to make team decisions when the stakes are high, and it'll be something along the lines of: Have a strong process, and make it the responsibility of one person to follow the process, which should involve gathering information and driving the consensus of the team on that issue. Give that responsibility to someone already established to have good people skills e.g. a lead. What would be your approach?
Hey there. I wrote the Jai Primer. Ideas there are my best interpretation of Blows ideas, which I generally agree with, but bear in mind they're not his.
To quote Joe Armstrong: You wanted a banana but you got the gorilla holding the banana and the whole jungle. You wanted a way to delete memory automatically, which sounds great but in practice most language's approaches to solving this problem come with a host of other problems that at scale make the given solution not worth it. RAII solves a big problem but it introduces a bunch of tiny problems like big mysterious constructors that implicitly do a lot of work and deconstructors that don't map to any particular line of code other than an ending brace. It's tough to examine in a debugger, it's tougher to reason about when it gets to nontrivial scale, etc etc. But human brains naturally weight a lot of small pains to be less bad than one big pain, so the solution looks legit.
Polymorphism is a way of modeling the world that runs along the lines of the categorizations that people tend to make, so it feels natural to create deep class hierarchies. But in practice it doesn't match the problem that you need to solve when you make games - you have data in state A and you need to get it into state B. Example: to do a physics integration on each simulated body, the CPU wants to do a for loop over a list of position vectors. But those vectors have been scattered all over memory by the class hierarchy. So that's one problem, you also get problems like needing RTTI and casting and yadeya. Class structures have largely fallen out of vogue in game development in favor of component systems, which is a pretty good step forward.
Hello, dev of docs.gl here. I would be happy to support WebGL but I don't use it myself so I've not prioritized adding it. I'm happy to work with any enterprising person who wants to help add it :)
I scraped the docs from the Khronos website when I started the project, about ten months ago. They may be getting out of date by now. At some point I intend to check out all of the changes that Khronos has made since them and apply them to docs.gl. Help maintaining it would be much appreciated :)
I went to add the additional error code and I noticed that Khronos says the invalid operation error should be thrown if texture is NOT the name of an immutable texture object. Is it me or is that not a copy paste error that shouldn't be there?
I would love for people help improve the language, which I agree is terrible in places. I don't consider myself an OpenGL expert so I haven't tried to improve the language except in places I know very well. That's why I went for including examples instead of reworking the language. But I would be thrilled if some good writers helped clean it up and expand and clarify etc.
There's a button above the command list that lets you hide stuff that's not available for the version that you have selected. It should be core for all GL versions. If you select 3.0/3.1 then the fixed function stuff is there but when you select 3.2 it gets removed. It's possible the page's design isn't clear here.
The rest of your stuff is in my to do list. Thanks for the feedback. Pull requests welcome :)