Yes I agree with you, the point is that being technical person doing a technical job I thought that the value that I create will talk more than the nonsense of some people. As I like to act first and share later, but there are people who talk but don't know how to act properly.
I can build this skills as you said, true, but in my position now it would be impossible to get a promotion as the available spot has been taken already.
>I thought that the value that I create will talk more than the nonsense of some people.
Nope. Silence is always less noticeable than noise.
Evil prevails when good men do nothing. Also, nonsense fluff prevails when good work isn't spoken of.
You have a professional duty to make sure nonsense is crowded out by important information. No one is going to do that for you.
Follow the rule of three...tell people what you are going to do and why it is important. Tell people what you are doing. Tell people what you've done. And not just anybody; decision makers.
It is no one else's job to tell people who influence your life of your good works.
No one has time to dig through everything you might have done to hold up the shining examples of your work. And now you have someone above you that might actually be interested in seeing it kept buried so it is even more critical that you do that interpersonal information transfer yourself.
You are a business, and like a business there is no worth in a product that the people who are in a position to buy don't know about. You're going to have to market and sell your value to the people that are buying. All of the time. Make it a habit. Your co-workers are competitors...don't expect them to sell your product for you. (though, keep in mind, part of your value-add is cooperating in your value-add chain so don't take this analogy too far).
Honestly, this is stuff that took me way too long to learn. They should teach it in engineering school. Hell, they should teach it in secondary school, for that matter, since there is really no one who is not running a business even if it is a business of one.
> Follow the rule of three...tell people what you are going to do and why it is important. Tell people what you are doing. Tell people what you've done. And not just anybody; decision makers.
An interesting corollary: Find out what's bothering decision makers. What're their annual or quarterly (or whatever) goals? If you know what those are - not only can you say "Hey, by the way, I did what I'm being paid to do, but, by the way, it helps to address that thing that's been bugging you."
Cannot agree more, this is a life lesson that should be taught in school.
Especially in medium/large companies where you got rewards like promotions, bonuses and so on, then your colleagues are competitors.
Pretty much like politics, the one over promising and under delivering wins over the quiet one that delivers.
...if everyone is over-promising & you're confident in your delivery, all you need to do is "promise" something between what is expected & over-promised in order to "under-promise".../
,,,
...
,,,
...
This is excellent advice. This is one thing I've found myself struggling with as (like the OP), I have had this naive idea that the work will speak for itself.
Often, when you do good work and are good at what you do, it actually looks like your job is easy, even when you are busting your ass to get results!
Some of the best engineers I remember working with did the over-communicating stuff you advise and I remember it was always very clear what they were working on versus other people. They also had a knack for communicating the work in the simplest terms for everyone to understand.
I find this prevailing mentality incredibly troubling and the one truly broken thing about North American culture. Taken to its logical end, it is the underpinning root cause of all that ails the U.S.
In short: “I did it all myself” is always a lie. It could only ever be true if babes were left in woods since the time of birth to fend for themselves, and even then, debatable.
Really?
It seems pretty easy to fall into a group dynamic where one person gets the technical debt dumped on them while the other handles the non technical aspects. This is because it is easier to not communicate and just do everything yourself than to explain to someone who is less technically motivated, for whatever reason. When you slow down and try to explain stuff over and over, until at a certain point as the gap increases it feels like the other person is either incompetent or taking advantage of the situation to reduce their own workload.
Unless you can make the leadership recognize the greatness, there’s no difference between ridiculously shitty code that works, and beautiful, well-organized code that works.
Since you’re already in the position where you seem to lead the technical efforts of the team, where would you like to go from there?
There is a difference of course though and it's important to market to non-technical people that readable, maintainable, and tested code really does lead to lower costs for the company in the future.
> there’s no difference between ridiculously shitty code that works, and beautiful, well-organized code that works.
Unfortunately that's not true. If "shitty code that works" requires three days to be understood in order to make a small change that became a delivery issue and three days in a problem that can be solved in one hour are $$ that somebody is paying. In addition "shitty code that works" most of the time has scalability and performance issues sooner or later you need to address if you don't want it to implode.
> where would you like to go from there?
I can also keep staying in this position, I just don't like to have a manager that I'm not even proud of. And, by the way, I'd like to be in a position where decision making is more stronger also in a business perspective. There are a lot of ridiculous choices that some people makes that are not very effective in some ways let alone make data driven choices. As the organisations today claims to be "agile", most of the time they're not at all. They just use a new word but act as old school (long feedback-loop just to give you an example)
I had a cat. The cat would do stupid stuff while I was away and when I'd get home I'd get angry and smack the cat with a newspaper. Then someone told me: the cat is like a small kid: if you punish it after more than 5 minutes, it doesn't associate the punishment with the "crime".
People outside your team won't understand your reasoning. They'll see code working one day and a random failure a long time after that, which might or might not be related to the previously working code. They're just like my cat.
If you want to act for "shitty code", act before it's in production. Afterwards it's very hard to dislodge. And even harder to pinpoint the blame, as the author will definitely protect his back, ethically or not.
I'd take the experience as a lesson in human interactions :)
> Unfortunately that's not true. If "shitty code that works" requires three days to be understood in order to make a small change that became a delivery issue and three days in a problem that can be solved in one hour are $$ that somebody is paying. In addition "shitty code that works" most of the time has scalability and performance issues sooner or later you need to address if you don't want it to implode.
I think you might be missing their point. From the perspective of a programmer, yes, these things are true. Code SHOULD be Good and Right™, and that is very easy to see and grok from a programmer's standpoint. But to a manager? These things usually have to be stated explicitly, and that isn't entirely the manager's fault. It is easy and pervasive in the industry to write crappy code that works for a variety of reasons (time constraints, incompetence, poor decisions from on high, etc...). Even the best managers have some degree of "out of sight, out of mind" because they rightly delegate the responsibility of making sure the code works AND minimizes tech debt to the developer. It doesn't become apparent to them (and by proxy, the business) that the code was poorly written until the shit hits the fan.
Also, it is unfortunate that you have to leave that job. In my experience in the industry, being able to go back and fix tech debt like you are describing is very uncommon.
Has I said in another comment it was made out of request by the manager and director. They asked us to clean the code since we were experiencing issues due the volume. Without the changes that we were asked for today the company could not even be able to sell their product online.
> there’s no difference between ridiculously shitty code ...
I side with you on this because of something I see often: At the end of the day what the CIO (a purchasing manager or the budget signer) asks about is who killed the fire for the day. When you are the good fireman, no one wonders about the quality of hose you used ..
The root problem is that there are too many idiots in management positions; they can't see through all the bullshit.
Also, there are too many dumb investors; our entire global economy runs on dumb money. Don't waste your time trying to create value;
let other people create the value and focus all your energy on capturing that value.
When's the last time you went out of your way to discover if and how someone else has done well?
Now, when's the last time you went out of your way to discover if and how someone screwed up?
The difference is just how people are wired. We are all kind of dumb.
As a fun exercise, track down someone responsible for having made your life better today, find out exactly how they did it and give them a piece of your mind about it.
I have spent my entire career in your area and can say with 1000% confidence that "the value that I create will talk more than the nonsense of some people" is something that EVERYONE assumes to be true when they start but EVERYONE realises is 100% incorrect after a few years in the industry.
I've been reading a book on nonviolent communication[1]. It's been helping me rethink how I approach work conversations and communicate what I want.
Putting it into practice has been tough, but early results have been good. I'm less likely to get angry, and while I still am not necessarily getting what I want all the time, I feel like I'm getting more clarity and direct communication around why not.
I can build this skills as you said, true, but in my position now it would be impossible to get a promotion as the available spot has been taken already.