beersigns

I've been where you are, once about four months ago and once six years ago. Both times I stayed longer than I should have. Both times I hit the same burn out symptoms you describe: hating my daily grind, barely limping through the day. Both times I ended up quitting and eventually landing on my feet at a new job. It can be really hard to walk away, but the damage you do to yourself can really hard to walk back if you let it go too long.

It can be hard to find a fulfilling/challenging/engaging job and it's equally hard to find companies with a culture that doesn't slowly eat away at your sanity. If you can find the latter, it makes a menial/less interesting job better. It's a great deal if you can find both, but it seems like a cultural fit is more likely to help you through what sounds like a very tough personal stretch.

Getting some advice/support is always a solid option in circumstances like this. It might be a former co-worker, a former boss, a family member; whatever works to give you a positive nudge in the right direction.

Another thing I'd recommend: try to find some solace in hobbies or personal interests. If it's a physical engaging activity, so much the better: hiking, climbing, biking, lifting weights etc...It has served me very well over the years and helped me through some rough patches in my own life.

Good luck out there fellow traveler.

I'm currently working with a lot of younger developers and I think most would benefit from reading this type of article. The first bullet point is one I find myself referencing very often.

The tip about revising the on-boarding document regularly is an another very good one. The best team environments I've been a part of had a very detailed and up to date on-boarding/env setup docs.

I had a similar experience once but a little more extreme. On a take home interview test they were asking to build a full backend analytics setup plus a data viz UI. I called the recruiter back and told them an estimate to a problem like this was well beyond the ~4 hours they originally told me. Their response was to say "they were looking for people who would find a way to get it done no matter what". I immediately stopped the interview process without looking back.

Think most companies resist using lower level languages due to their ultimate purpose being to build products that provide value and sell them. They are generally far less concerned with the technical details and conciseness of the implementations. "Good enough" is a very squishy term but for most companies, for better or for worse, that bar is pretty low. There are plenty of industries that focus on lower level langs and use them pretty well but it's not the norm for big corporations who value rapid turn around over all other factors.

Yeah, I'm lucky enough to be able to locally use the prebuilt binaries of seabolt for OS X. I wasn't so lucky with my deployment of it, which is on an alpine container. Definitely not a lot of fun installing the C toolchain & compiling from source but it is doable.

The only pure go bolt driver doesn't have the full feature set but has potential: https://github.com/johnnadratowski/golang-neo4j-bolt-driver

Interesting to see neo4j released an official Go driver. Java, Javascript, Python, dotnet and now Go have an officially supported bolt driver.

I'd agree with this, I've had good experiences and downright painful ones with performance reviews. I've always found the process outcomes are heavily influenced by the relationship with my manager. I feel like you need a certain comfort level discussing with them or it tends to fall into that "Waste of Time" the author is referencing.

Came to say something similar; I see it with library choices a lot as well; poor library choices ~= sloppy programming. I've had a lot of issues in the the past with 'conventional wisdom' lib choices that result in a lot of re-work as predictable issues with those choices arise.

Yeah, I've not delved deeply into the details of his life but that would make sense. Have to imagine she was there providing that day to day support and helped give him purpose.

There are many reasons to celebrate Stephen Hawking but the one I personally am most impressed by his ability overcome an ALS diagnosis in his college years and go on to live a life of such distinction. It takes some serious courage to soldier on after hearing you may only have two years to live and know that at best you will live a life of slow & debilitating physical deterioration. I'm not sure I could face a such a prospect, so many of the things I enjoy in life require full motor skills and then some. I'd like to think I could adapt and follow such a bold example provided by Stephen Hawking. His story is truly inspiring to me and I hope his story inspires others to do great things.

I generally agree we are products of the environment/circumstance we are born into but it's left to your free-will and choice as to how to best persevere in that environment. I've always viewed talent as the tool that enables you to make the best of the environment you are placed in. Chance/opportunity is not a equally distributed resource but by working hard/efficiently you prepare yourself to make the best of the opportunities you are presented with in life. No one is immune to sheer bad luck but if you did everything you could to set yourself up for success, you shouldn't be derided for it.

I've had a lot of success with paired programming in different team/project environments and really have only done 'mob' experiments. I didn't find there to be a lot of benefit to mobs vs pairing unless the goal was to make sure every team member was highly aware of what was going on in a specific commit/feature-branch.

I definitely think ad-hoc mobbing has it's place and most if not all big design/redesign work the team undertakes should be in a mob form. I'm not sure I could see it being a good practice day to day for most teams/projects though.

I'm not sure I'd classify myself as a loner(married, fairly large social circle) but I definitely value my self reflection time. I do think I tend to be more 'dense' in my social interactions as the article suggests. Ie if I"m gonna spend a lot of hours doing something social(parties, meet-ups etc), I'd prefer there to be some observable benefit. There are plenty of ways to I know of it improve/expand my knowledge on my own: skunkworks projects, reading etc. Think it's pretty much like anything else in life: find the balance of alone time and socialization that works for you and you'll be healthier and happier for it.

Getting x509 issues. Output is below:

$ httpdiff https://www.google.com http://www.google.com

Doing GET: https://www.google.com http://www.google.com

Error doing GET https://www.google.com: Get https://www.google.com: x509: certificate signed by unknown authority

I'm sitting behind a pretty heavy proxy though; could be that. That or OS X(10.9.5) certificate store issue maybe?

This was a pretty thought provoking read for me; it put into words some of the beliefs I have operated by. However it's also important to remember that to be 'doing' you need to have a clear picture of why you're doing what you're doing. A lot of people I've met(and myself at times) do not know what they want to do; they've only learned about things they don't want to do in their experiences. I do agree it's best to gravitate towards projects that truly interest you though; if you don't believe in what you're doing you risk drifting into complacency.

I had similar experiences with pairing; often it was mandated by folks in charge who didn't seem to have a great grasp of what the benefits were. Productivity/velocity tended to suffer noticeably on many teams. It worked for others, but I think most times it wasn't understood fully why it worked for a given team.

What bothered me about how I saw pairing used was that people seemed to make blanket assumptions about it's benefits. Many times I saw people pairing up on trivially easy tasks. Seemed to me that pairing was a lot like everything else, it can be done well or poorly.

Pairing should be a naturally occurring process IMO; ie I don't know how to best accomplish a task or 'story', so I ask a team member w/expertise or experience to help point me in the right direction. If I need help beyond that, it becomes a pairing/knowledge-transfer exercise. I came to refer to it as "informal pairing". In general I tended to gravitate toward pairing on the exceptionally difficult tasks or ones that would have far reaching design implications.

This was initial thought as well, seems like both would fit the needs specified, multiple column search etc. I've had good experiences with both ES and Solr. They both have pretty healthy user bases and are well documented. Only hang-up is if you use primarily reg-ex style searching; turning on n-grams could work there, but it might be too slow.

I've always considered IntelliJ as the Cadillac of Java IDEs. Eclipse(or plug-in modded Eclipse) seems to be the most common in places I've worked. NetBeans seems to be less popular than either.

I'll agree with the working out regularly being good for your health, both mental and physical. Exercising has gotten me through some tough spots in my life and it has always been a major coping mechanism.

Another thing that has always worked for me has been laughter. Whether it's watching a classic movie like Dumb & Dumber, reading reddit/r/funny, or catching The Colbert Report, laughing eases all the little things that otherwise might eat you up.

I mostly have a case for the extra grip. I had issues with dropping it and have basically a grippy rubber sleeve for a case. I've probably dropped 10 or so times and I'd guess 1 or 2 of them would have have caused cracks with out the case.

I work in a very large company that has primarily Java for web apps and back end processes in COBOL/Mainframe environments. I've been steering things towards Groovy or Ruby for new projects, largely using productivity as the justification. Top push backs from upper management have been: 1) Universities we recruit from teach Java & most prospective employees already know Java 2) Costs of retraining workforce 3) They don't understand those langs can be utilized with our current JVM ecosystem

I feel pretty much all those reasons are specious and really shouldn't be holding things back. We've got a foothold established with success of some smaller projects using Groovy and Ruby to "prove" their viability. I'd like to try Scala next to see how it would fit for some of our other projects.

TLDR: At least one large company is making efforts to evolve beyond just Java in the JVM.

There's a novel I read years ago that had a similar idea. It was a Clive Cussler book: The Mediterranean Caper. The smuggling plot had a modified submarine containing the narcotics attached to cargo vessels & it would detach from the cargo vessel at inspection times. It wasn't a great book and it felt kind of James Bond villain-esque but the concept is sound.

I've been that interviewee before and I was much the same. For me I realized it has to do with viewing the time spent in the interview as some kind of unspoken contract. You both felt good about the interview but you aren't accepting. Feels like you're letting them down.

Hah, my own anecdotal evidence has been in favor of smaller teams for the communications reason you cite. Probably a bit of a bad analogy but it made me think of 3 Unix processes vs 30. Way harder to manage IPC between 30 processes as opposed to 3.

Communication/Collaboration & ability to write elegant code are pretty symbiotic but I'd generally say it's harder to find someone who can elegantly design/code a system than it is to find people to talk about it(Reqs, specs etc).

That is the result of a environmental/social dice roll. Not even close to the same thing.

I'd argue all of those areas you list are far more likely to be improved over the course of a lifetime than sheer intelligence. Pure intellect is pretty much set at birth, or at the least the ability to improve it isn't statistically significant. I'd argue that genetic dice roll and environmental dice roll are quite different things as well. You have FAR more ability to change your environmental situation than your genetic one. Does everyone have an equal chance to alter their environment? No, but who said life is fair?

I'm on the same page. IQ is property of the genetic dice roll, not something that a person earns. Tangible results based measurements seem more appropriate. Pure intellect is the raw material & needs to be refined/applied to be useful.

edit: grammar

I'm on board with this statement. I've realized for quite awhile that there are some guys who are just on another level in terms of sheer ability. Sadly I am not one of them.

I've run across a fair number of the 9-5 guys who used to be really good/good & use that as motivation to never allow it to happen to me. Always gotta push forward.

The man who knows he's not wise is in fact wise?

I actually agree to some degree. Though it could definitely said that it's easier(less time & struggle) for some to create great programs than it is for others.

My entire life as a programmer has been about consistent and constant improvement. A little bit of improvement every day, every project. Committing to the craft(reading, exploring new langs/tools) will definitely allow you to create better and better code as the years go by.