91–100 of 129 posts
I like how Google lets employees use 20% percent of their time to work on other subjects that their current projects. More companies should do this. The value is huge: less bored developers, less burnt out developers, innovation and development of potential very useful features for the company.
> It's never something we need to hide, but instead it's something we're eager to share with our teams - ala "hey, I did some research on X, and maybe this is something that could be valuable for us to try". I'll give good odds that in most shops, if you pull this line more than a couple of times, your management chain is going to decide you aren't picking up enough work in sprint planning...
It depends. "Let's change to " is annoying. But if you do a little more research and reframe the problem to make it simpler, that's just good senior dev work. Understanding the problem and finding what the business really needs instead of diving in.
- What will it cost
- What problem will it solve
- What advantages will it bring
- What disadvantages will it cause
, then there would be no reason not to bring it up. Maybe I'm just jaded, but when you try to bring up these points, people often (subconsciously?) try to "sell" their suggestion instead.
Sharing my limited experience. In any way or form I don't imply that my point of view is right. Producing software is complex process that requires constant adjustment and change. I have successfully run my company (middle level web-shop) and delivered results for more than 16 years. In my PM practice I never required my engineers to do "extra". In my view this is not productive approach at all. Creating the adequate…
Can't that extra be something unrelated to your current project? I like how Google lets employees use 20% percent of their time to work on other subjects that their current projects. More companies should do this. The value is huge: less bored developers, less burnt out developers, innovation and development of potential very useful features for the company.
Now, I spend maybe 1 day a week working on a personal side project where I can get all that energy out of my system. Every 3 months or so, I will find a very useful nuget in the side repo that I can gently introduce to our product repo.
Earlier quoted context omitted.
I think the author needs to elaborate more on "extra". I've been on both sides and I know what Ben is referring to. This isn't about showing off so that your boss thinks you're not busy. I think OP is trying to encourage people to care about their job to the point where they want to do it better. I think what he means is: doing extra is insurance. It is knowing your job more than just punching a clock and getting the…
Sorry, I’ve been doing your ‘extra’ for years. While it earns you kudos and respect, it rarely gets you promoted, if ever. Playing politics on the other hand is lot more successful.
Earlier quoted context omitted.
Such a cop out response. "Politics" is interacting with your peers, your superiors, clients, vendors, etc. It's being able to articulate why your ideas are better from technical, organizational, and/or business perspectives. When you have ideas that shine in one of those categories but are absolute shit in the others, or when you have decent ideas but are terrible to work with, it's much easier to just get defensive…
Wow! I think we would all like to come work for that perfect organization where you've found a place. Perhaps I am the only person in the world who has ever heard the phrase "office politics", but, in my experience, as ileight2 says in an earlier comment, internal politics can supersede any other consideration (including money!) in any country, market, organization, and time period. I've found myself, peers, superior…
I say this as an introvert and as a person who chooses words carefully to reflect my best guess at the truth, which non-engineers commonly mistake for lack of confidence in product/estimate/my ability. Dealing with architects (or even seniors) who can't sell their vision or opinion and/or fail to amicably disagree on technical issues is always a painful experience. It does not have to be that way.
I feel like the people who do "extra", never feel like they're doing extra, they feel like that is part of the job. The example of "creating two screens", you make the screens, and then look at them and think...is this the best I can do? Is there a better way to protect the security? Is there a way I can reduce the boilerplate? Can I refine this so it's easier for somebody else to maintain later? That's the job, as f…
They don't give you time because they expect you to do so on your own accord. It's part of your job description. Another part of your job description is to make sure your manager is too busy managing, and doesn't have the time to micro-manage your time.
If they have enough headspace to tell you NOT to write unit tests, they aren't effective leaders.
that said, there's a difference between refactoring and rewriting a thing in a different language. At this point in my career, I'd be VERY hesitant to do the latter. The time spent in a rewrite is better spent refactoring and updating the existing codebase. It's just not as sexy on your CV.
Earlier quoted context omitted.
That's actually a great point and a downside to extra work. Maybe the middle ground would be to do extra work for fun and not bring it up, or just finish work early and work on something altogether separate on the side?
Do extra work, and do present it, but pretend it only took 30 minutes when it actually took five hours. Congrats, now you get credit for the extra work and you're a "10x rockstar".
Really interesting article about enabling longevity and success as a software developer, but it matches my view on all kinds of skilled work: whatever your employment arrangement, treat yourself as an old-fashioned professional. Like a doctor or barrister, more tied to your profession than to one job. You need to be effective in your role, build your reputation by demonstrating your skills are beyond the bare minimum…