Might not help if you're stuck in an authoritarian micro managing matrix but some tactics I've found useful before.
1) Block out 3 hours in the morning and 3 in the afternoon in your calendar as busy, marked private, at slightly different times each day. If asked you can be honest, many times people will not ask and simply avoid booking.
2) Leave your least productive time of day open for 90 minutes of meetings - for me this was post lunch.
3) Always reply and ask for an agenda so you can be sure you're necessary (it's a constructive way of making the requester think twice about whether they really need a meeting).
4) Often suggest a new time that is only 30 minutes long rather than the default hour.
5) Decline politely if you are not specifically necessary (Thanks for the invite Peter, appreciate being kept informed but I don't think you need me for this and I have a conflict - no need to reschedule for me).
But mainly just look for a way to leave. That company is heading down the tubes.
I'll add one that even after 200 comments I don't see: Failure to explain the reason why. Coming down to their developer with a list of tasks without explaining why those tasks are the most important and will lead to company success.
You might think startups are small enough that this couldn't happen but that was actually where my worst experience was. The founders are visibly in a meeting with a couple people, maybe "suits", maybe not. They come out of the meeting and the next day your priorities are rewritten. Cool beans, that's a thing that can happen and that's not my issue. My issue is, why? What are the goals we are trying to hit now? What's the plan? Why is that better than the old plan?
This is especially important IMHO for more senior engineers responsible for architecture and stuff, because those matters can greatly affect the architecture. Telling me why lets me start getting a grasp on what parts of the code are long term and what can be considered a short term hack, what the scaling levels I need to shoot for, and all sorts of other things that are very hard to determine if you just come to me with "And actually, our customers need a new widget to frozzle the frobazz now more than they need to dopple the dipple now."
Not necessarily the biggest issue, there's a lot of other suggestions here that are probably bigger in most places, but this is one that has frustrated me.
(I'll also say this is one you may be able to help fix yourself, simply by asking. If you are in that senior role I think you pretty much have a professional obligation to ask, and I would not be shy about working that into the conversation one way or another.)
I believe the number one problem you will run into is what happens to every wiki in the world. Knowledge goes stale and discovery is hard. Especially when you don't know what to look for.
Making content is never the answer to passing on institutional knowledge. This problem was actually solved very effectively a long time ago by trade unions such as the masons.
Start by having an apprenticeship program. Shore up any missing skills and teach someone how to apply them at your institution. Go into the meaning of why you are teaching them.
Second, set up a simple progression where one builds a base of understanding to move to the next phase of institutional understanding. Apprentice (learning) -> Fellow (perfecting) -> Master (can teach).
Masons don't even write anything down and have managed to pass on institutional knowledge for generations. Martial arts communities are similar.
"Programming" is easy. You pick a language, learn a set of rules, and over time learn how to tell the machine what you want it to do in that language fairly well.
Software development is hard. Unlike many other building tasks that humans run into, software is rarely "done". Launch of software for most of us means the code we've written has just been promoted to a point where now it's important, and will likely be what we work on for the near term future.
So, what makes a good software developer? Generally, programming's the smallest part of that puzzle. Working effectively with others ranks up there. Business acumen. Communication skills, both written and verbally. Understanding release cycles, revision methods, standards, etc. All the things that developers don't want to care about because they aren't writing code, those are the things that make good software developers.
I hope the prices for these coffees come down, though I get why business-wise it makes sense for them to target the ultra-high-end market at their stage. The idea of good coffee from somewhere as close as California is a bit exciting to me.
---
Sorry if the rest is slightly off-topic. After reading all the comments here about the coffee prices mentioned in the article, and seeing what every considers "normal" prices, I feel compelled to make the following PSA:
Save your money and roast your own coffee at home, if you are able to (* more on that below).
I've been doing this for about 3 years now. There's a small learning curve, but as Kenneth Davids puts it in his book [1] (paraphrasing): "The difficulty of roasting coffee is somewhere between frying an egg and making a good hollandaise".
I buy my favorite coffees from around the world as dried green beans for around $5-7 per pound. Furthermore, coffee greens can last quite a while in your pantry if kept in well ventilated burlap sacks (a couple years, or more). This allows me to stockpile like 50 pounds of coffee to roast throughout the year. Also, there's really nothing that quite compares to coffee a day or two after it's been roasted. I can easily brew way better coffee than most coffee shops here in Austin, TX (though there's a couple exceptional ones here with more time/skill/resources than I).
To roast coffee, my low-budget setup is:
- A heavy pan / popcorn popper (mine: https://www.amazon.com/Zippy-Pop-Stovetop-Capacity-Stainless/dp/B00PFRRA0Q)
- A portable heat source (I use an induction range)
- Colander / wooden spoon / shop fan
- A well-ventilated outdoor space (a balcony does just fine), there's smoke / messy chaff
(* if you don't have access to outdoor space, it can be a deal breaker)
Every week, I spend about 20 minutes total roasting a new batch of coffee (end up with ~12oz roasted). Total equipment investment for me was like $150. I can also enjoy some really great espresso with my budget setup (manual lever machine + Pharos hand grinder), but doing that well is a steeper learning curve.
I remember reading this published insight[1] from Marissa Mayer a few months ago:
Burnout is caused by resentment
Which sounded amazing, until this guy who dated a neuroscientist commented[2]:
No. Burnout is caused when you repeatedly make large amounts of sacrifice and or effort into high-risk problems that fail. It's the result of a negative prediction error in the nucleus accumbens. You effectively condition your brain to associate work with failure.
Subconsciously, then eventually, consciously, you wonder if it's worth it. The best way to prevent burnout is to follow up a serious failure with doing small things that you know are going to work. As a biologist, I frequently put in 50-70 and sometimes 100 hour workweeks. The very nature of experimental science (lots of unkowns) means that failure happens. The nature of the culture means that grad students are "groomed" by sticking them on low-probability of success, high reward fishing expeditions (gotta get those nature, science papers) I used to burn out for months after accumulating many many hours of work on high-risk projects. I saw other grad students get it really bad, and burn out for years.
During my first postdoc, I dated a neuroscientist and reprogrammed my work habits. On the heels of the failure of a project where I have spent weeks building up for, I will quickly force myself to do routine molecular biology, or general lab tasks, or a repeat of an experiment that I have gotten to work in the past. These all have an immediate reward. Now I don't burn out anymore, and find it easier to re-attempt very difficult things, with a clearer mindset.
For coders, I would posit that most burnout comes on the heels of failure that is not in the hands of the coder (management decisions, market realities, etc). My suggested remedy would be to reassociate work with success by doing routine things such as debugging or code testing that will restore the act of working with the little "pops" of endorphins.
That is not to say that having a healthy life schedule makes burnout less likely (I think it does; and one should have a healthy lifestyle for its own sake) but I don't think it addresses the main issue.
Then I finally realized how many times I've burnt out in my life, and I became much better into avoiding it. Which is really hard to do.
And it seems to me that this is one of the many points that Ben Horowitz talks about on his What’s The Most Difficult CEO Skill? Managing Your Own Psychology[3]
> I see a lot of pro-Erlang/Phoenix pushing in here, which is (as a polite reminder) an announcement about the rails framework. Not to say that one shouldn't, just that I think it's deviating from the main topic in hand.
You're right basically, but the migration wave from rails to phoenix has noticeably started, and it shows.
> Interestingly, I wanted to find out what's the real reason behind these pushes towards Erlang/Phoenix and I realised the discussion is mostly around how you can save a few bucks worth $20-50 by opting for a faster programming language.
Actually, the high performance stuff and Rails-y organization of phoenix is just something to give you immediate benefits and a sense of familiarity. It attracts people and give them a reason to try it out. Beginners praise it, but it's by far not the actual reason to keep pushing phoenix. Just like
"hey, it works like rails, you can do everything with it like rails does, so there is just a small learning curve and we have orders of magnitude better performance!"
> Any framework can be tuned to do anything.
Yes this is true. You can also write OOP assembly or use vim as a bitmap editor like paint. The point is: while you can theoretically do everything with mostly everything, the results will differ a lot and the way to these results will vary a lot.
With phoenix, there is no "magic" (people complain about this in rails!), everything is simple, explicit and straightforward. You also do not need many third-party tools like redis, sidekiq or memcached. This greatly simplifies the application code, reducing brittle constructs/bindings.
Currently, Rails still has the edge when it comes to gems, many things are readily available. This helps when "getting started" for typical app scenarios.
But a few weeks in, maintenance is the most important factor when it comes to development speed. Here Phoenix wins by a large margin. Less dependencies, easier code, less performance tuning, less bugs (compiler/dialyzer/... arguably).
> Rails right now is the only truly comprehensive framework with tight integrations to Coffee, LESS, CSS, etc.
The asset pipeline of rails can be quite a pain in the ass. Phoenix went a different way by integrating brunch, the probably easiest of the node.js task runners, which mostly doesn't even need custom configurations. (npm install --save brunch-less, your less files are integrated as you'd expect. Same for coffeescript, ...).
> If you run a business, then all this small talk shouldn't matter as much as how profitable you are. In the end, if your business failed because of your choice of framework (which usually reflects your philosophy), then you need to fix your business model and not the framework.
The development speed does matter. when you waste time optimizing things, fixing bugs with dependencies or stuff like that, you aren't shipping features. Moving fast is crucial for startups.
And then there is scaling. Phoenix is known to handle large loads with ease, and probably most startups can go a long way before they even have to consider horizontal scaling. Not having to think about this is worth more than the money you'd throw at servers to scale up rails (which, as you said, isn't needed in that quantity in phoenix either).
And just a personal note on top of this: Once functional programming/elixir "clicks" for you, translating business requirements into working code is so much easier as functional data transformation with pipes than having to deal with forests of class structures. For many cases, it just makes more sense (and is easier to read, maintain, extend and test).
---
Finally, the actual big win of phoenix is BEAM/OTP. Performance aside, the thought model of OTP just makes so much sense and simplifies building reliable, distributing systems a lot. I'd argue that OTP is the true reason people are blown away, elixir simplifies the syntax/reduces boilerplate, and phoenix on top makes getting started a breeze, looks like rails on the surface, and once you get into how OTP works, you're hooked.
I do, I've been a heavy user of both for 4+ years, but I'm not a security expert of any kind.
LastPass has been exploited a few times in ways that could have given up passwords. Their UX and server infrastructure seems to be a mess of php scripts, that itself doesn't have to be insecure but is a code smell. Their commercial support looks unmaintained. Both platforms support "cloud" based syncing but since 1Password's is pretty new I can't speak to it.
1Password does local encryption outside of the browser, LastPass will encrypt locally in the browser.
1Password can leverage other file transports to sync passwords, iCloud, DropBox, or any shared directory. LastPass does it all with their servers.
LastPass's web interface if compromised can have you give away the password to all your passwords. 1Password has a much smaller risk of this and would probably have to include a malicious software update.
1Password Families/Teams exists and I'm not familiar with it but it probably has a similar attack vector to LastPass's web interfaces.
You know, they both offer end to end encryption with similar attacks. Overall these companies are big targets and I'd rather keep my passwords offline or synced via side channels in a standalone app like 1Password.
PS I'd be amiss if I didn't mention dashlane https://www.dashlane.com/ I hear good things and it's passed review at a few companies who know their stuff, but that's all I know.
I used to believe that every company gets one rewrite, but only because I have seen that most places have the patience and the stamina for a little bit less than a single rewrite, but I was on the fence about whether they were a good idea anyway.
Trouble is, I could never put my finger on why, other than that it never seemed to fix the problem. It was a bit like moving to a new city to start over and finding out you brought all your problems with you.
In the last couple of years I have begin to figure out what I know in a way I can articulate. The people who have the skills and discipline to take advantage of a rewrite don't need a rewrite. It's a short distance from that skill set to being able to break the problem down and fix it piece by piece. They just need permission to fix key bits, one bite at a time, and they've probably already insisted on the space to do it, although they may be clever enough never to have said it out loud. They just do it.
Then you have the people who don't have the skills and discipline to continuously improve their code. What the rewrite buys them is a year of nobody yelling at them about how crappy the code is. They have all the goodwill and the hopes of the organization riding on their magical rewrite. They've reset the Animosity Clock and get a do-over. However, as the time starts to run down, they will make all of the same mistakes because they couldn't ever decompose big problems in the first place, and they lack the patience to stick with their course and not chicken out. They go back to creating messes as they go, if they ever actually stopped to begin with. Some of them wouldn't recognize the mess until after its done anyway.
In short, people who ask for a rewrite don't deserve a rewrite, and would squander it if they did. It's a stall tactic and an expensive dream. The ones who can handle a rewrite already are. They never stopped rewriting.
Now, I've left out all of the problems that can come from the business side, and in many cases the blame lies squarely with them (and the pattern isn't all that different). In that case it might take the rewrite for everyone to see how inflexible, unreasonable and demanding the business side is, and so Garbage In, Garbage Out rules the day. But the people with the self respect to not put up with it have moved on, or gotten jaded and bitter in the process.
1) Block out 3 hours in the morning and 3 in the afternoon in your calendar as busy, marked private, at slightly different times each day. If asked you can be honest, many times people will not ask and simply avoid booking.
2) Leave your least productive time of day open for 90 minutes of meetings - for me this was post lunch.
3) Always reply and ask for an agenda so you can be sure you're necessary (it's a constructive way of making the requester think twice about whether they really need a meeting).
4) Often suggest a new time that is only 30 minutes long rather than the default hour.
5) Decline politely if you are not specifically necessary (Thanks for the invite Peter, appreciate being kept informed but I don't think you need me for this and I have a conflict - no need to reschedule for me).
But mainly just look for a way to leave. That company is heading down the tubes.