|
|
jschell wrote: Harassment based on race is specifically illegal in the US.
Unless you are a Democrat. 
|
|
|
|
|
|
|
|
Well no one should be fired based on their ethnic background. Sounds like your manager is a real jerk and you should report him to HR or his manager.
At the end of the day that's the reason large companies like that have an HR dept in general. To make sure they are protected from liability issues and it sounds like that manager is a liability issue.
Good luck~
|
|
|
|
|
Haven't heard Tom's version.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
This is the most unethical thing to do and now when everyone says that we are united and we respect each other's culture and values then this is not at all acceptable. As far as an employee is considered then if they are loyal and sincere towards their work they should be given equal respect and appreciation.
|
|
|
|
|
Most asians people that I know are hard working and are been appreciated by the boss and colleagues .Maybe that is not the issue. Amazon gained a lot of profit during the pandemic. Idk if the salary of your boss has increase or not tho...
|
|
|
|
|
Odd that you make a post of that question and have never returned to comment. Sorry, that puts the question in question.
|
|
|
|
|
This question was actually asked on a Quora and I wrote the following answer. I thought this would be a better place to put the answer so I am copying and pasting here.
Ahhh Lucy code. I worked on a team of three programmers once. It was almost a former lifetime. Two of us wrote fairly decent code. 1. Named Lucy did not. She used Goto statements. She named her variables name1, name2, name3, textbox1, textbox2 etc… It was horrible.
The manager loved her however. 1. She was a girl on the team so that helped the powers that be say we are diverse. (whatever. Bad work is bad work). and she could very quickly get a first draft into a persons hands to react to on screens and other things. She was very good at getting a project started. without thinking about the end goal.
Buttttttt and it is a huge one. She would have trouble finishing or modifing anything she worked on. And Brad and I would flat refuse to even look at her code. IF when we were forced too. We informed our manager that it would take a week of clean up before we were ready to even start on the actual changes for improvements. Also, she could not update her own code. She would spend days just trying to figure out what name77 did and what kind of variable it actually was.
It took a very long time. Like a year or more. But eventually the manager started seeing that Brad and I could update each others code easily. and that we could jump into any project either of us had done and keep going when the other was out. Lucy on the other hand could not even with her own code. Eventually we started pushing for code reviews infront of the manager and pointed out the variable naming and the spaghetti like structure of her code. And then we would ask the dreaded question. How long will it take for you to update this if the customer decides that the zip code should not be an integer and now should be alpha for overseas deliveries? How long will it take you to find the various textbox1’s on all the screens and actually know which one houses which database information fields?
about 2 months of that and Lucy got mad and quit our team.
PS Let me be very clear before anyone goes off on me picking on a woman. I have worked with a ton of wonderful lady programmers. They have been awesome. I have worked with some bass Akwards male programmers. Lucy just happens to be the worst of the worst for programmers that I have encountered,.
To err is human to really elephant it up you need a computer
|
|
|
|
|
Personally, I believe that they should be hangèd (worse than normal hanging!) from the nearest lamppost pour encourager les autres. This, however, may get you talked about. 
If mentoring fails, one possibility, as you mention, are code reviews. Another would combine code reviews with a "style manual". If it becomes necessary to fire the offender, it is much better to do so for egregious and repeated violations of company rules than for something vague like failed code reviews.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Quote: She was a girl on the team so that helped the powers that be say we are diverse.
Thank God we're still not here and judge people by merit, not by gender, race etc... At least most of us
|
|
|
|
|
rnbergren wrote: Let me be very clear before anyone goes off on me picking on a woman.
You didn't document the experience level of any of the developers involved.
If you were all juniors then I question the very assumption that the other two developers code was as good as claimed.
If she was a junior level and the others were senior then it was a failure in management. And if that was not brought specifically to the attention of management (the need for mentoring) then that is a failure for the seniors.
Also the description suggests that major functional pieces were being developed independently by each developer and nothing in the description suggests that formal or informal design sessions were carried out. Which again was probably a senior level failure. Technically in that situation then the delivered code is not 'bad' because the process is in fact 'deliver what works'.
rnbergren wrote: And then we would ask the dreaded question. How long will it take for you to update this if the customer decides that the zip code should not be an integer and now should be alpha for overseas deliveries?
I am not a great fan of developers that think their code will support future features when those features are not known. I have seen lots of complex code written like that where is did not provide any benefit and did in fact make maintenance much harder (and cost more.)
If you knew that the code would require it to work for a global market and she did not then there was a process problem.
If she knew it but did not meet the requirements then that is a different problem. And also does not really meet your original assertion that the code "worked".
|
|
|
|
|
well I think it depends on the time at hand, if there are really tight deadlines and the management does nothing about it and the developer is paid as a junior, it is fine...
|
|
|
|
|
Do the job that you are being paid to do. Just that. Nothing more. Nothing less. Do that job to the best of your ability without adding beyond what you are being paid for. Exactly what you are being paid to do: Do that. Only that. Do it well.
|
|
|
|
|
Hi, I recently came across this site on hacker news: BugUFO: Get paid to debug code[^]
And applied for an invite but wanted to ask if anyone has gotten in before and if so, what are your thoughts are about them?
|
|
|
|
|
I applied for an invite as well. I like the design. I like that you can sign up as "both."
|
|
|
|
|
What were some “red flags” new hires shouldn't ignore when starting a new job?
All Credit to
Don Sevcik, President of MathCelebrity and Author of 2 books
Updated Jul 4
Let’s discuss 10 red flags to watch for within the first 3 months of your job. 3 months gives you ample time to find. My credentials for this answer: 20+ years in the corporate America cube farm. Fortune 500, mid-level, and start-ups. Ready…Let’s go get it.
1.Has your job, in the first few weeks, suddenly morphed into something different from the job role on your employment contract? And, if you call management out on it, and they use silly phrases like not “being flexible”. Congratulations, you’ve found your first red flag
a.Aside: If you learn nothing else from this post, read this: “Flexible” and “Team Player” mean do more work, but not get paid for it. Learn this quickly. Because the most important thing every morning is waking up, looking in the mirror, and being able to respect yourself.
2.If you work in a job as a “doer”, such as developer, builder of things, etc., do you find yourself booked up in many meetings? Then congratulations, you’ve discovered a red flag. “Doers” should not be in too many meetings. Because gasp…they need time to actually do stuff. If management cannot squash this early so you can do what you do best, you’ve found yourself at a mismanaged company.
3.In the first few weeks of joining a company, do you notice lots of “cliques” and keep running into “unexpected, unspoken rules?” If so, you’ve dug up another red flag.
a.I remember working at a company years back, doing development. In my interview, I was crystal clear…”I don’t like filling out a lot of paperwork to push code. I just want to code, test quickly, and push it out there.” Alas, 3 weeks after getting hired, management “revealed” that every code push needs a 3 page document filled out, a web form filled out, 3 layers of approval, just to get a change in. It’s ridiculous. The more red tape, the bigger the red flag.
4.Does your company push “social-time” off hours and unnecessary get-togethers? Do they push, and I mean push charities, social justice groups, and other hootenanny garbage? Congratulations, you’ve found another red flag. Nowhere in any standard employment contract anywhere, does it state you must be active with charity, social justice causes, and any of that other garbage. Nor should it, because none of that has one iota to do with your job and the company making money. Not one iota. So if it’s pushed on you, run for the hills.
5.Does your company value “in-office” time more than they do accomplishments during your work hours? If so, you’ve found another archaic, and detrimental red-flag. If I get 8 hours of work done in 2 hours, then what I do after that shouldn’t matter. Because, it’s not like corporate will pay you more for additional effort. Great bosses will let you leave early and give flex time when you pump out work quickly.
6.Do scheduled meetings always run over time, or start late, or both? Congratulations, you’ve found another red-flag. Time wasters. Also, meetings, especially corporate meetings, are notorious for posturing and politics. And if you aren't a fan of meetings like me, then this is a HUGE red flag. Meetings should have an agenda, allow no rambling, and get to the point quick. As in, who is doing what, who needs help, and when can we expect things to get done. That’s it. No more.
7.Are you having a hard time finding a document about annual raises and bonuses? As in, you do “x” and “y”, and this is how you advance. And when you ask about it, does your manager hem and haw or avoid the subject. Congratulations, you’ve found another red flag found at 90% or more of corporate jobs.
8.Does the majority of people at or above your level use unnecessary buzz words to describe something? As in, can you find a word from grade 5 to grade 7 on the Flesch-Kincaid reading level to replace their silly buzzword, and not only keep the meaning of what they were trying to say, but enhance it? Congratulations, you’ve found another red flag. The key to communication is simplicity and clarity. And buzzwords violate both those rules. And if we can’t have a simple conversation about “my contract” and not “annual incentive protocol”, then we have a red flag on our hands.
9.Do the dumbest people get promoted, and the superstars get passed over or marginalized? Congratulations young padawan, you’ve uncorked another red flag. And this, like #7, happens at 90% or more of corporate companies. It’s red flag football, and you never score a touchdown.
10.Does your new company change “direction” every 2–4 weeks? Pat yourself on the back detective, you’ve found another red flag. If management cannot figure out what to do, and they get paid large coin to do one job, then you’ve found yourself at an insane asylum. Best to pull the cord and exit stage left.
Heed these 10 rules my friends, they just might save your life down the road.
Quote: Don's linked in Account
[^]
To err is human to really mess up you need a computer
|
|
|
|
|
11. When a new person is brought in to lead your business unit, do they bring in their own people to replace several existing managers? This can be legitimate when a business unit has been run poorly, but more often it's a sign that the new leader wants to be surrounded by buttlickers.
12. Is a lot of time spent polishing PowerPoint presentations? This is a strong sign that form and style are more important than substance. It often goes hand-in-hand with people who are good bullshitters having more influence than people with proven track records.
modified 3-Oct-19 17:06pm.
|
|
|
|
|
13. Management people with no technical background review code to ensure it's properly written.
May sound surrealistic but actually encountered it on one of my projects.
Also, you may find this article relevant
|
|
|
|
|
I believe there would always be red flags with every company. What's the take here? Think it's more of 'knowing it'. As an action, there are multiple things at play always. Like:
- Search for a new job has its own toll on mind and body
- What if all the effort made to get out of this red-flag zone but again land into another one. That would be really frustrating!
- How will my changes from one to other company reflect on my resume (and probably a true answer on an interviewer!)
As much above flags are really true and there, what would help is to have some ways to cope with it sooner than later. Everyone has their own way to handle and that's on individual on how they deal with it. Believe it would turn more towards what keeps you calm and let you continue.
|
|
|
|
|
Hi
Apologies for the long post, but there is a more directed question at the end of the slightly rambling background.
In September, I started working for an offshoot of another company, but since then, our IT departments are merging, and the cultures are completely different. In our office, established for just over a year there's me with bags of commercial IT experience, plus a guy with a PhD in aeronautical engineering, excellent dev & very quick on the uptake working with C# & SQL where possible.
In the other office they have been established over 10 years and the IT is doing the job the company needs, but there are no good practices.
Some examples :-
Virtually all development is in Python, which is run as a mass of scheduled tasks. There is one particular task that runs around lunchtime to pick up all the submissions from the previous day, and another to pick up the same class of thing to mop up what has come in today runs at around 5pm. Each is a separate python script with a couple of classes declared at the top (which are declared in virtually every script I have seen), followed by around 1000 lines of code mixing in database access, processing logic & composition of output XML in a single block of code with nothing split out for readability. The two scripts differ in four lines - they don't appear to have heard of parameters.
Also, they don't appear to have heard of stored procedures; I have seen scripts where, to get nested information, they run an inline query to get a set of data, then walk the set in Python & fire a separate query to get related information for each row.
Did I mention that they have no form of source control?
I really need to change the culture in the other office (I do have my boss's support in this). I started by going in there & demonstrating a bit of separation of concerns using classes in Python and unit testing, then leaving a copy of Clean Code with the guy who seems to be the main trusted developer who people look to for advice, but it sat on his desk unopened for 2 weeks.
On the plus side, a young guy (just 18, left school at 16, started in the warehouse & moved into development purely because he showed an interest in it) emailed me to say he hoped it was OK that he had taken the book home at the weekend to read, and is picking up C# with remote assistance from me. He's mega-keen & will probably make an excellent developer. There are other developers who also seem willing to learn, and they have all said that that the guru is very set in his ways.
So, any ideas on how I can start moving them towards learning sensible IT practices as a matter of course? I feel the main obstacle is the guru chap, but he has the trust of his non-technical superiors, so technical explanations may be wasted on them.
One possible light is that we will be examining the code of a product developed by a third party, written in VS Code C# - I'm hoping it will open their eyes to the possibilities, though I'm not looking forward to explaining <t> notation to Python devs, should it arise.
Regards & TIA
|
|
|
|
|
First, the bad news. Without support from Management, changing the culture is impossible.
Having said that, incremental changes are possible. For example, start with things that have obvious benefits, like a version control system. Emphasise the benefits - rollback abilities, change tracking, etc. Then, continue to other tools. Introducing new (to them) ideas such as stored procedures should be postponed until you have built up some credibility with Management in the new company.
Good luck!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It sounds like you are on the right tracks. I would say have a look at the the Mikado Method[^] together with unit tests to ensure that you do not break anything on the way.
Basically making small changes as you go along adding unit tests to ensure that your changes are correct.
I sort of get what you say about stored procedure but I find myself in a situation where most of the business logic is in stored procedures which is a nightmare in its own special way.
Also get them to watch the Uncle Bob videos, just as a way to introduce them to good coding practices.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
