I fully agree with your comment about whale tasting like crying, I have a profound regret over eating it....but...not sure why...as I eat pretty much ever other animal.
The lobster in iceland was amazing though.
We did a summer week long roundtrip around it, it was amazing and would love to go back.
I would say you need to keep in mind that delivery of the team against product commitments should be a priority, and being able to do that in a long term sustainable way is very important. So in my view you should absolutely put out of your mind what you'd like to do and instead view it as what is the best way to complete the task at hand ( and making sure that can happen in a consistent reliable way). I'm a EM myself and there's no way that my day-to-day is consistent enough to code in a reliable manner especially when put up against other priorities that I have to deal with. What's more important?, you finishing a business critical feature you signed up for or helping a team member with crisis they are having dealing with another team member? (Or if you are more tech lead than people lead then compare it against more long term strategy planning and architect-ing you could be doing.)
- Google questionnaire and spreadsheet for food options.
- Laptop plus usb cables/audio cables for peoples music collections instead of a DJ (gotta trust you're friends taste though).
Never use unproven tech for a mission critical deliverable :)
One thing that helps me avoid notifications is turning my screen to greyscale, notifications are way less visually distracting then. Only problem is that WhatsApp 'read' ticks colour scheme means that in greyscale the sent and read colours are the same so can be a bit annoying.
This is giving me fond memories of things I had to do or had heard about from colleagues:-
- To improve game loading speed of a CD - Load level on PC from hardisk, log all filenames loaded to a txt file and then use that to order the files when writing to the final CD.
- Load all files into PS1 devkits memory, write out all memory in a binary blob to the harddisk, burn that memory image to CD to use for fast level loading (just load it in a single fread(..).
- have separate executables for different levels which had different features, to save memory.
- Write a small block allocator to make <256byte allocations quicker and more efficient.
- Find a tiny piece of memory in the PS2 IOP chip which doesn't get wiped on a devkit reboot (for some reason) and use that as 'scratch' space to write log messages to track down a hard to repro crash that rebooted the kit.
- Change the colour of the tvs border to different colours to track down a race condition that only existed on burnt disks and we had no debugger. The border colour setting code was quick enough to not affect the race condition, so choose some places in code to arbitrarily set to certain colours, burn the disk, test it, when it crashed see what colour the border was, then put some more colours in possible areas, re burn the disk and etc (so basically binary search the code areas using border colours).
- Use compiler optimisations settings for 'size' instead of 'speed' as the smaller executable code size meant you stayed in the DCache more which actually made the code quicker than compiling for 'speed' which resulted in generally larger code.
- Burn a master CD image for publisher, get the game ID code wrong, open up the disk image file in a hex editor and manually edit it rather than go through the whole build process again.
- have no build machine (Gold master got made off whatever code the leads machine had).
- Use sourcesafe (no atomic checkins....)
- Use a few batch files and a directory share for 'source control' of art assets.
- Have values in config files we gave to games designers which did nothing (this was accidental but they swore changing them made a difference to the game).
- Have a advertising deal with a company to have a special cheat code in the game to unlock some stuff, the programming code that does this has a bug that ships that means you have to alter the code incorrectly to get it to work....so tell the company that 'Your code was too easy so we made it harder'.
- Have a developer write code like this as he swore that passing a extra parameter would have slowed the game down:-
(psuedo code, but original was in C)
I agree with your disagreement. If you don't care about your people and team and don't put them first then it's highly unlikely you'll actually be in any way productive to give the company what it needs.
I guess the way I view it is that company is the destination and team/people is the journey.
This way isn't the only way though, I've seen teams run 'company first' it generally involved a lot of unhappy people and I didn't like it, so I avoid that style personally. A friend of mine seems to pride himself on being a 'hard driver' and being 'brought in as the hammer', ; but to each their own.
I view my relationship like the stock market, it'll have its up and downs, sometimes I'll be ahead, sometimes the market/she'll be ahead and I'll be down....but overtime the stock market generally goes up so it'll all be fine in the end.
My wife tends not to like me describing our marriage like that though :)
I created some specific 'coffee' time slots in my calender and use https://calendly.com/ to organise the time slots (and put location details etc in as well) and then I just occasionally post to LinkedIn with the link saying I'm open to chats. I tend to get 1 or 2 every time I post.
It's definitely not 100% effective but works for what I want at the moment.
I offer to meet random people for coffee several times a week, sometimes it turns out to e networking, sometimes it turns out to be ad-hoc advice/mentoring, I just try to put myself out there for people to use as they'd like and see what happens.
blunt feedback after spending a few minutes looking at it.
- Get a better photo, current one makes you look weird, can't tell if it's being arty or just blurry.
- Try to break up wall of text summary, a few line breaks or spaces would do wonders for the readability.
- Bullet point skills and responsibilities for your previous and current roles; same for education as well.
yes do it, setup 30mins per person every 2 weeks, in the meeting invite describe this is a time for discussion, feedback (for you to them and them to you), for things like career progression and also for them to ask questions they might not feel comfortable asking in a more public setting including things about product, company etc. Try to keep the time as consistent as possible and show that these are a priority for you (so don't forget, cancel them etc).
They can be tough conversations, but rewarding on both sides.
If you are leading a team of devs at the very least read these 2 books:-
First off, managing people is not a 'promotion', it is a complete job change. It is not a incremental increase on previous skills or job expectations; it is radically different and you must be aware of that if you want to succeed.
If the company considers a move from a individual contributor to a people manager a promotion then it is disfunctional.
Ignore this whole concept you have of 'playing politics right', you have wayyyyyyyyyyyy more important things to deal with. 8 devs will keep you very busy with 1:1's, career guidance, mentorship along with day to day running and long term more strategic less tactical planning.
Reset your expectations on the problems you will face and have to consider; your entire world is about to change (if you want to be a decent manager).
Cut scene might have different shaders than in game, generally cut scenes are far more controlled and so might have higher quality shaders than in actual levels. And also that solution would only work in games with cut scenes and you would have to assume so cut scenes occur before the levels with the needed shaders in. So it would end up being a very brittle solution.
Sorry not a startup manager; but people manager at one of the bigger tech companies, hope it's still relevant to you
Main surprise was how much I had to become truly aware of exactly what I was saying and doing every moment of the work day, as the team really do start to embody what you project and that are directly influenced by you and how you act on every level. I knew this would of course be the case going into the role but seeing it play out in subtle ways of peoples behaviour is surprising. Without sounding condescending it can be like a parent, what you do becomes the standard even if you didn't intend it to be.
Do you mean if you do an in-place upgrade? or a VIP swap? A inplace should just go through the update domains so if you have your extra 20% provisioned as normal it should be fine and a VIP should be pretty quick and painless.
You shouldn't really be getting 'promoted' from engineer to engineer management. I know it always happens but it shouldn't, being a good engineer does not mean they'll be a good people manager.
If you're just starting this new job (and it is a new job) and you're considering 'maximizing the teams impact' it assumes that you'll in be a good manager and be able to run a team at any efficiency at all. Which is putting the cart before the horse.
You need to start from the basics of people management, just start reading everything and anything you can regarding people management, definitely including non-tech people management.
You WILL make mistakes, you will grow massively and you'll find yourself dealing with problems you might not want to; such as a dev team member missing meetings, or you trusting a team member to deliver something and they tell you 5 mins before the deadline that it won't get done (despite them saying it was all going well), or someone asking why they aren't getting promoted as they've been there for years (but you know they aren't quite cutting it). Or someone wanting vacation during a deadline period. Or in yearly pay reviews you have to choose who gets what and you know that that actually affects their lives....all these things can weigh emotionally on you. Or you needing to recommend that someone gets fired. Or how do your organise a morale event for your team which is inclusive as possible given everyone on your team but also people actually like and increases morale/celebrates your team.
Listen to your team, accept that you're learning, use data to guide your process decisions, be open and honest to your team, learn how to communicate up and down, find a mentor. Decisions you make now affect people as well as code.
It's fun and enjoyable, if not a tad stressful (just think that your job is now debugging people rather than code...and people have wayyyyyyy more race conditions....).