I was referred to a lawyer by a friend who was laid off previously. Many people were being laid off at this time.
Also, I worked with lawyers at the company I was employed with. I asked one lawyer who I got along with to refer one. That referred lawyer was too expensive (big name law firm who works for corporations).
If you don't know any lawyers, you can ask anyone who works with lawyers. For example, if you have a friend who is banker or real-estate agent. Their lawyer will know other lawyers.
Most importantly, you should have a conversation with a couple lawyers (ie. interview them): "Here is my situation, do you think I can get more?", "If we ask for more, how do you go about it?", "To keep costs down, do you have a legal associate to do the work?".
Since you are interview them, calling local employment lawyers that you find on google is OK too. The 15 minute phone call is free, lawyers have to do marketing/business development too.
On a different topic: you mentioned stress. My advice to you is to make sure you don't turn it into a bad time in your life. You have control. You can make it better by doing things such as losing weight, improving your golf game, traveling locally/camping (to keep costs down), visiting family, building a side project, contribute to open source. All of these things give a silver-lining and promote a positive optimistic outlook. Also, these things are great in a future job interview when they ask "so what did you do with your time off?" A fun, positive answer is best. You won't be unemployed forever.
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 know it's commonly recommended here, but the other Rands' book, Being Geek: The Software Developer's Career Handbook, is top notch as well for devs and those living somewhere in-between experienced dev and team manager.
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.
