The CitiCar Is an Electric Cheese Wedge from the 70s [video] - <AUTHOR> https://www.youtube.com/watch?v=ilIozuRmTQs <comment><USER2> Why's he so snarky about it? It seems like the design is intentionally low cost. It's not supposed to be luxury car. Could have been perfect at the time for people who just need to go a couple of miles every now and again. Just an enclosed golf-cart really. What's wrong with that?

<comment><USER3> "All citicar's Have defroster switches; none of them have actual defrosters."

It's too bad he didn't say why (presumably he wasn't able to find out), but I think that deserves at least a little bit of snark.

<comment><USER4> The Wikipedia page says having a defroster button was a federal regulation.

</comment></comment></comment><comment><USER5> This presenter is incredibly entertaining. He seems to strike a nice balance between a classic car expert and a very amused normal person. This was super pleasant to watch!

</comment><comment><USER6> My friend had one of these in the 80s. Even though it was pretty clunky, I've wanted an electric car ever since, but nothing seemed practical until the Tesla.

</comment><comment><USER7> He didn't say how they were sold - dealers - mail order, etc, or how they were marketed.

I don't recall ever seeing one, or even hearing of them, which makes me wonder if they were marketed at all in Los Angeles back then. I wouldn't be surprised to learn they were not.

<comment><USER8> Surprisingly, I found one in Carterville, Illinois back in the early 2000s. It's the only one I've ever seen outside an episode of "3-2-1 Contact" back in the early 80s.

I distinctly remember watching television, seeing a street full of these things and thinking, "Why would anyone want an electric car? They look stupid." And you know what? The did. Every electric car looked stupid, including General Motors's EV-1. That is until the Tesla Roadster.

Tesla may eventually flame out in a pile of debt and mismanagement, but Tesla changed the industry by making practical electric cars that looked like cars that someone would want to buy. There's no going back from that. Kudos.

<comment><USER7> I'm surprised I never heard of them. Any car company startup that sold over 2000 units in a year back then would have been very notable.

I suspect it's because they really weren't a good car for LA which was built for cars from almost the beginning. The hills and traffic would've be horrible for the CitiCar.

And yes, Tesla has changed the industry and has been the only American car company that really has in the past 70 years, which is truly remarkable. I'm still amazed at how much they've moved the entire industry.

I hope they keep on going. What they (we) really need, and I'd expect they're working on it, is a smaller, more affordable car. "A car for the masses", something in the $15-25k range. It won't need any of the self driving functions and 100-150 mile range would be enough for the target market.

</comment></comment></comment><comment><USER9> Cheese Louise: [https://www.youtube.com/watch?v=hXzcIoq2ing](https://www.youtube.com/watch?v=hXzcIoq2ing)

</comment><comment><USER10> I can't imagine why electric cars had such a bad reputation until 2011...

</comment><comment><USER11> My old roommate repaired one of these a few years ago and drove around in it often (in Mountain View). It was a bit impractical because of the max speed (30mph) and range, but fun to ride in once

</comment><comment><USER12> Interesting to see this car drive through the streets I grew up on in Ferguson, Missouri.

</comment><comment><USER13> i kinda want one. feels like a fun restoration project.</comment>


Wikileaks releases the Egypt Cables - <AUTHOR> http://www.guardian.co.uk/world/blog/2011/jan/28/wikileaks-latest-developments

<comment><AUTHOR> I can't believe they waited until the egyptian internet was taken down. They should have put this out days ago.</comment>


The Merry Pranksters Who Hacked the Afghan War - <AUTHOR> http://www.psmag.com/navigation/politics-and-law/the-merry-pranksters-who-hacked-the-afghan-war-60873/ <comment><USER2> World is small. I spent a winter there, working with the Synergy Strike Force. One thing led to another and I ended up coaching the regional basketball team:

[https://nplusonemag.com/basketball-diaries- afghanistan/](https://nplusonemag.com/basketball-diaries-afghanistan/)

Here are some photos of home base:

[https://www.flickr.com/search?user_id=68877611%40N00&text=ta...](https://www.flickr.com/search?user_id=68877611%40N00&text=taj%20afghanistan)

One of my best basketball players, an Afghan, and SSF member, is now a Fulbright in the US:

[https://www.flickr.com/photos/ifl/13007763495](https://www.flickr.com/photos/ifl/13007763495)

@rdl don't believe we've met but nods to you.

</comment><comment><USER3> Hey, he received military funding to ultimately try and do good in a crappy situation, hats off to him.

</comment><comment><USER4> Directly taking funding from an occupying army to manipulate popular behaviour in to a centralized intelligence gathering system, then claiming some form of moral outcome for the greater good? Somehow I missed the connection.

</comment><comment><USER5> Antz: [http://sourceforge.net/projects/openantz/](http://sourceforge.net/projects/openantz/)

</comment><comment><USER6> I also saw this on [https://tinyletter.com/intriguingthings](https://tinyletter.com/intriguingthings) 5 Intriguing Things, a daily email by Alexis Madrigal I would highly recommend.

</comment><comment><USER7> Loved the "Beer for data" approach. It could work in a lot of other settings. Very novel idea to mine data from otherwise hostile environments. Does he publish this data online?

</comment><comment><USER8> Wow, what a guy.

</comment><comment><USER9> So this dude siphons off of the military industrial complex to feed both his addictions and his narcissism? Count me out.

<comment><USER10> I visited/helped out a tiny bit with these guys.

It really wasn't about ego on the part of the people I encountered, so much as frustration and genuinely wanting to see things happen.

They actually had a hard time raising money because they needed/wanted to stay under the radar. After Mehrab's death as far as I can tell things shut down.

<comment><USER9> Fair enough. Sorry to be so harsh. I think it was the tone of the article that made me upset yesterday. I definitely realize the need for accurate information in that part of the world!

<comment><USER11> For me it was less about the data for beer (which in and of itself was brilliant) and more about them using government (and their own) money to set up small positive projects for local people.</comment></comment></comment></comment>


If the internet is addictive, why don't we regulate - <AUTHOR> https://aeon.co/essays/if-the-internet-is-addictive-why-don-t-we-regulate-it <comment><USER2> We don't (and shouldn't regulate it for the same reason we don't regulate the post office simply because some people misuse it. Shooting the messenger is always a bad idea.

Articles like this confuse (either deliberatly or from ignorance) the _internet_ with the _endpoints_. What they really mean is some people find _Facebook_ addicting[1], or some people find certain _games_ addicting. Regulation _is_ needed in many of these services that _use_ the internet - just like any other service.

[1] also, operant conditioning != addiction

</comment><comment><USER3> I find the idea scary.

Government regulation has a history of fucking things up creating problems even worse than the one meant to be solved.</comment>


Google+ API released - <AUTHOR> http://developers.google.com/+/api/

<comment><USER2> Hmm, to be honest, I did expect a little bit more after waiting for three(!) months now …

The hype seems to have settled. Now I hope that Google can come up with some more details to their API soon, so developers can start building interesting tools for this new ecosystem. If they wait another three months, I guess it will be too late.</comment>


Show HN: I built a webapp to make OKRs easy to use for individuals - <AUTHOR> https://focusokr.com <comment><USER2> I'm sure it wasn't the the intent - but the company logos feel dishonest and suggests that they or at least a number at those companies uss your site for their OKRs... which I know is not the case.

</comment><comment><USER3> Looks good, daring color scheme.

What's with the big brand logos? What do they mean?</comment>


Dealing with insubordination - <AUTHOR> https://www.softwareteamlead.com/getting-on-board-dealing-with-insubordination/ <comment><USER3> >All the lead wanted was a single private variable placed in the class and the amount of effort it took to get that accomplished was a multiple day discussion. There are processes in place to get things like this removed. If you are iterating and being "agile", then you can remove it later realizing your mistake, and if you code it right, then it will not be intertwined into code so deep that is causes a delay.

Based on this explanation the lead wanted a quick hack put into the code and the developer didn't want to write it (probably because it was a bad idea).

So here's how you solve that. Get the developer to find a solution to whatever the problem the hack was solving. Give him a deadline. "If you feel this strongly about it, find a solution by tomorrow morning, or we need to put this hack in for this push."

Pretty simple. Going all micromanaging dictator who forces shit hacks won't be good for your department short or medium term.

<comment><USER4> > Pretty simple. Going all micromanaging dictator who forces shit hacks won't > be good for your department short or medium term.

The same could be said about questioning minor requests from someone who has more experience than you do and who has a greater responsibility to deliver on deadlines. Wasting hours of time over a single line is a great way to make people dislike you for being so inflexible, especially if it's holding up the work of others on your team.

<comment><USER3> If it's bad code, it's bad code. Good developers don't like to write bad code. Any experienced, good developer has most likely worked on a shit codebase and understands 1. that it didn't happen all at once, but trickled in and 2. it's debilitating to the organization. If you force good developers to write bad code, you probably won't have good developers much longer.

If I knew more about the circumstances, I could make a better judgement, but to me it sounds like the lead wanted the developer to put in shit code and he didn't want to. The thing about shit code is it costs 2x, 10x, 100x of technical debt later. Remember the article is written from someone biased towards the lead.

<comment><USER5> Senior developers know that wasting two days fighting would be better spent elsewhere. This is an example of a midlevel programmer who can program but doesn't understand the big picture. Probably the type of person to follow one way of doing somethig and freakout on anyone who suggests something different. This developer doesn't get it... they need a few more years of seasoning.

The lead is in charge of making those decisions. Having a working feature in time for the sales demo is more important than some code purity.

They do not understand the difference between getting paid to do a task vs creating a personal hobby project.

<comment><USER3> >Senior developers know that wasting two days fighting would be better spent elsewhere.

I disagree. Sometimes, yes, but most of the time, no. Two days fighting can save years of maintenance costs (and I'm assuming productive fighting, not fighting for the sake of it). Ever developed on a not-well-thought out database model? No foreign keys? No consistent naming? Dates as varchar? You're stuck with it. It not only causes more defects in existing code, it makes enhancements harder and more prone to defects.

But it's hard to speak up on such things. It much easier, mentally, to just say screw it and write the bad code, especially if someone is non- confrontational by nature.

<comment><USER5> You are not stuck with those things. Converting dates or adding references or changing the customer model or even migrating to a different type of database are things you would normally do when you start scaling anyways.

The code doesn't have to be perfect aligned to some doctrine.

If you feel the need to fight back over a single private member variable delay some important release the reasoning must be better than one day in the future it, it will make development slightly harder. Refactoring is a good practice.

<comment><USER3> >are things you would normally do when you start scaling anyways.

It is (sometimes but rarely fundamentally different refactoring) but when a crappy schema has been built on for years, it is exponentially more difficult to refactor, especially a live system with multiple clients and uses. The best (and cheapest) medicine for that is to not inject crappy design in the first place. Sometimes you have to, but it should really taste bad.

>The code doesn't have to be perfect aligned to some doctrine.

If the doctrine is not putting crappy / hacky code in the code base if you can at all help it, I think that's a fairly standard doctrine.

>If you feel the need to fight back over a single private member variable delay some important release

I'm not sure if the article said the discussion would delay a release or that the release was important. All those absolutely do come into play though. If they were in play, you'd think the dev lead would have enough respect for his team to point that out.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> The company I work for is Dutch (very egalitarian, consensus-based work culture), hires only people with academic degrees (love to argue), has a very flat organisation (very little hierarchical power to make anyone do anything) and on top of everything else, it's a consultancy with a software development branch at heart, and the programmers are told the same thing as the consultants -- be visible, have an opinion, make it known, and so on.

So this is completely typical for every single ticket and the team lead is powerless.

What works is: let the team know the planning, make the whole team feel responsible for making the planning, ask this programmer to make this ticket happen, let him come to the same conclusion as you regarding the planning (argue), and then have him figure out how to solve it in half a day. He'll probably also add the private variable, or come up with a similar way.

Alternatively, add the damn private variable yourself, if it's only a single line.

Trying to force people to do things on a level of detail that is well within the area they want to decide themselves doesn't work.

"Team lead" isn't "team boss".

<comment> le-mark Subtitle of the blog explains a lot:

 _Views and insights on leading a software team through experience in military leadership and on the job experience with enterprise level software products._

I've seen many, many prior military people utterly fail in the civilian work force because, guess what? You can't just bark orders and expect to get anything done. You can't belittle, berate, and batter civilians with words the way leaders are encouraged in the military.

 _Front leaning rest postion, Move!_

 _Five zero, knock em out._

Good luck being able to type at keyboard after 50 pushups.

<comment><USER7> I've seen many, many projects in the civilian workforce fail because, guess what? Not everyone gets to be CEO and CTO.

Sometimes leaders are wrong, and sometimes those who should lead are tyrants, but sometimes folks need to get in line and follow.

Different situations are different.

<comment><USER6> I've argued that in our company, _at least_ there should be someone on a team who gets the official power to be tiebreaker, to just _make a decision_ when some discussion of whether to walk around the park clockwise or widdershins today just keeps going on on and on... But that's just not how it works here.

</comment></comment></comment></comment><comment><USER8> I've had a fair share of this crap myself being the team lead at the time. I didn't go yelling at the dev for not understanding that my contract said team lead and the CTO failed to communicate that role or giving me the opportunity to communicate it. I spoke with the CTO and asked him to clarify the roles and gave him a clear choice. He decided against clear communication and I decided to take more money elsewhere.

The problem is oftentimes not the individual being insubordinate. Oftentimes the issue is that Roles and Responsibilities are not clearly defined.

This is especially an issue when one of previous colleagues on the same level is promoted to the higher ranking position. It's an even more common issue in big corp and govt. institutions.

> Implicit tasks are not always common sense.

There is no such thing as implicit tasks. There are implicit tasks, when you sit in your garage and found a company and one guy is a marketing wiz and the other a rockstar dev. You might even have a well working symbiosis then. Everything beyond that needs to(at least some extent) be defined.

<comment><USER9> >The problem is oftentimes not the individual being insubordinate. Oftentimes the issue is that Roles and Responsibilities are not clearly defined.

This is entirely possible too. I just had an experience where I unwittingly cut the technical lead of my team out of an important conversation simply because I didn't realize he would care. I wanted to limit the scope of the conversation because of time constraints.

I told him to his face in a meeting that I was trying to limit the scope of the conversation. He was not very happy about that.

Needless to say, once I realized what a butthead I had been, I apologized profusely, explained that I had misunderstood the situation, and promised not to let that ever happen again. It ended up being fine after that, but boy did I feel dumb.

Point is, don't just assume that new hires will automatically infer what everyone's role is.

</comment></comment><comment><USER10> > Lead: This is not a choice. I am telling you to do this.

> Teammate: You need to convince me.

I think the teammate's at least half right on this one. Nobody does anything without wanting to do it. If you want somebody to do something, you _do_ need to convince them. If they'll do it just because you say they have to, they're still probably harbouring some resentment about it, which won't work out well in the long term anyway.

At least this guy was big enough to stand up for what he believed in.

> Just write the less than 80 characters line to add the variable and move on.

If it's so easy, why didn't the lead just do it himself instead of making a problem out of it?

<comment><USER11> I disagree. Team leads are chosen for a reason and when they clearly ask for a task, it needs to be done without the wasted effort of having to convince them.

> If it's so easy, why didn't the lead just do it himself instead of making a > problem out of it?

It's called delegation. If there are 15 easy tasks, a team lead can delegate them out using his or her judgement and have them completed quicker than doing it themselves. If each of those easy tasks has to go through a "convincing phase" it's no longer worth it.

<comment><USER12> A lead that squanders an opportunity to mentor isn't much of a lead.

<comment><USER11> I didn't say that one shouldn't mentor or receive feedback. I actually think if you disagree with the team lead you should let them know and then let them make the decision.

If they hear your opinion and still go a different way, that's fine - <USER2> with it. It shouldn't require every individual on the team to be convinced, that's a massive waste of time.

</comment></comment></comment></comment><comment><USER13> There's a lot wrong with this situation. Without knowing the person involved it's hard to say if they have an attitude problem, but it sounds like the team lead does.

>>Who is right? No one is right, but the lead has the authority to expect tasks to be accomplished when asked and has the responsibility of delivering the release on time.

There is something wrong when one has to defer to their authority to get things done. In this case it's even stated that there is no correct answer, so why does the lead need to have it their way?

There's also the small problem of what was asked. It's hard for me to believe that adding a private variable is actually implementing a product feature. This smells badly of telling someone HOW to do their job rather than WHAT you want.

And finally there is context. Sometimes when it comes to time pressure a phrase comes to mind "a lack of planning on your part does not constitute an emergency on my part." It would obviously be stupid to say that, but in _some_ cases it's the right attitude to have. It's not at all clear from this piece what the overall context is, what the actual feature is, or which person is being unreasonable.

I'm actually leaning toward the author as the problem. This need to blog about a petty dispute over a variable declaration suggests that _maybe_ the person not obeying orders could be pushing back against a larger problem.

TL;DR there's really not enough here to tell who the problem is, or if there is really much of a problem at all.

</comment><comment><USER14> This is weird. Author wants me to agree, that I have to unconditionally submit to someone because of their title. No ifs or buts, just do as you're told. I worked with people who loved to manage like this and in every single case when they asked for a wrong thing it was later developer's fault that he did something (it's his name on the commit after all). On the flip side every competent, cooperative manager I've worked with had no issue with people not wanting to do something. But yeah, YMMV. Perhaps in some bizarre world "I command you to do X" is the civilized way to talk to other people.

<comment><USER15> > I worked with people who loved to manage like this and in every single case > when they asked for a wrong thing it was later developer's fault that he did > something (it's his name on the commit after all).

So log your protest and the command in the commit message too.

<comment><USER14> Telling people "I demand that you do it" or even "do it, or else" is a symptom of a greater problem with said person. I don't see how waging battles with this type of lead in commit messages is going to help me.

<comment><USER15> > I don't see how waging battles with this type of lead in commit messages is > going to help me.

What a weird way to phrase it. The problem as stated is that the developer gets the blame because his name is on the commit message. If you document that you were specifically instructed to implement this commit, then that solves the problem.

</comment></comment></comment></comment><comment><USER16> Something about using the word 'insubordination' and linking to a dictionary definition that defines it as "not submitting to authority" and [being] "disobedient" really rubs me the wrong way.

Authority etc. are implied of course, in a team structure where there is a lead (and others are not), but if you told me to "obey your authority" in so many words, I would have a problem complying very easily.

<comment><USER3> I would say right now, good developers have more of an authority parity with business than any type of employee has ever had, based on scarcity and necessity. Hope it lasts.

</comment></comment><comment><USER17> Wasn't entirely sure if this was a sincere post, or some sort of unfunny burlesque of some kind. Assuming it's sincere, then the author of this blog post couldn't be more wrong about how to manage a software team. If a manager- type started going full-on micromanagement on me ("add a private var to this class now! rawr!"), bandies about the term 'insubordiation', and generally believes they're entitled to my unthinking obedience, then congrats: you've successfully convinced me to start floating my resume so I can get the hell out of that shitshow. I'm an educated, experienced software engineer with multiple degrees and life's too short to put up with that bullshit.

<comment><USER18> Well said.

</comment></comment><comment><USER19> The whole situation sounds ridiculous and the advice given is just awful.

A "team lead" should not be informing developers on the implementation details of their ticket. The developer had every right to protest.

> If the individual is not a fit, then move him to another team that might > have a different control style.

This is so backwards I don't even know where to begin. It sounds like the advice is to break up a team just to show the developers "who's boss." I would never want to work for this person. They put their own ego and control freak issues over the stability and productivity of the team.

Also, it's a super weaselly move that instead of just going to the developer in person and raising your concerns with him like a reasonable human, they used their corporate clout to bypass the issue and move him to another team. Is that acting like a leader?

</comment><comment><USER20> > Lead: This is not a choice. I am telling you to do this. > Teammate: You > need to convince me.

I've reached the point in a discussion with a subordinate where I've had to say "this is not a choice" multiple times in my 30-year management career. Only twice has the person absolutely refused and only one of those times was this part of the reason the person ended up being fired.

I'm amazed at how many times these kinds of ultimatums come down to some strange, abstract principle: "I won't pollute my code with a global setting, instead you're going to delay the release a couple of weeks while I re-write the code and we re-QA everything." No, that's not what is happening.

At some point, it is my job to make the call. If you think it is your job to make the call, you should find a job where it is your job to make the call.

I assuming, of course, your lead is not asking you to do something immoral or illegal. Since I've been on the other end of that before.

</comment><comment><USER21> When you have a team member being abrasive and insubordinate, sometimes that's just their personality.

But sometimes it's not. Is there something about your culture that isn't allowing them to make any of their own decisions, and they grasp for and fight to the death to defend every little piece of autonomy they can get?

Disregarding whether the disagreeable team member is right or not - it's entirely possible that when this happens, it is a symptom of bad management, and not the fault of the employee.

</comment><comment><USER22> A team is not a fiefdom. Using "authority" to handle conflicts likely won't lead to good results. Different people need different guidance, and overall management seems poor at dealing with people.

Also: "[implementing] a private variable in a class" is not a "task". A diff should be a single idea (i.e. have a purpose on its own). Adding unused code with no purpose just makes it likely that code will stay dead forever. In codebases I work in, an unused variable would be a lint error and that code could never ship.

> If you are iterating and being "agile", then you can remove it later > realizing your mistake, and if you code it right, then it will not be > intertwined into code so deep that is causes a delay.

It seems like the author hasn't worked with a large code base before. With a constant pressure to ship, dead code can sit around in your repo for a long while--and often good engineering initiatives aren't incentivized as much as they should.

<comment><USER23> > Also: "[implementing] a private variable in a class" is not a "task".

Haven't sit on very many task breakdown meetings, have you?

</comment></comment><comment><USER24> > This is the short version of how the conversation, but suffice it to say > that the teammate decided he was in control and wanted the team lead to > convince why he should implement a private variable in a class.

The teammate decided they're an adult. And looking at the "military" tag I'm not convinced the blog post author is.

> He isn't a bad worker, but the relationship between the leadership style and > his work style are clashing

The relationship are clashing? At this point, I'm really only interested in the view point of the person who so far didn't even get to speak, because the person talking about them I heard enough from.

</comment><comment><USER25> If the change is really so minor then it sounds like the employee is reacting against micromanagement.

What kind of agency are you expected to have if minor things like private variables are considered insubordination to authority? And then why would anyone want to continue working under a regime like that?

The manager, presumably being more senior, should have the maturity to know when to choose their battles.

I typically only intervene when I can see major architectural hurdles coming up, but I often see my colleagues fighting these stupid battles as managers and it's infuriating.

</comment><comment><USER26> _Views and insights on leading a software team through experience in military leadership and on the job experience with enterprise level software products_

Okay...

Does this guy have any articles on software bootcamp where drill sergeants scream at you to break you?

</comment><comment><USER27> Many people in this comment thread are assuming that a team lead has more experience, or he is more talented then the devs.

I am sorry folks, but this is not how it works. In many companies the earlier you arrive, the better chance you have to become the team lead.

Also nepotism is absolutely widespread in the IT industry. People just simply assign tasks to people who they TRUST. And no-one can tell me that trust can be quantified, because it cannot be.

Having said that I am not arguing that these things would be inherently wrong, it all depends how the team lead handles it's responsibility. If he has talent, he will make the team collaborate and get everyone involved.

If he is just a random guy assigned to a team for whatever reason and he is an anti-talent then he will try to micromanage the shit out of everything and everyone and will simply induce stress, burn-out and discontent.

Also it's a completely different point, but many people are assuming a "chain of command", "subordination" and mindless self-abasement. But the thing is that the dev only has to do as much as commanded by his contract/by the law. If the contract is unclear, then well, the onus is on the employer to make a better contract. So there are many unknowns in this story. But in any case, implying or expecting something without communicating it towards the dev is just simply unethical, unprofessional and lame.

Some other commenters also pointed out that if roles and responsibilities are not clearly defined, then that's gonna cause problems. I fully agree with this. And it's happening more often that not that companies hire people using a generic form which basically outlines the companies rights in detail but it doesn't say a single word about the employee's supervisors, expected skills and tasks or his responsibilities.

And as I argued in another comment below, transparency solves many of the problems which are raising from the failures I mentioned here. It just happens to be more popular to be exclusive, restrictive, restraining and secretive in management circles which is the exact opposite of being professional in my book.

</comment><comment><USER28> This is the first time I've encountered the term "BLUF". Turns out, it's the equivalent of TLDR - "Bottom Line Up Front".

</comment><comment><USER29> This sounds like a missed opportunity to coach rather than fix.

What if the lead had discussed the business objective and problem and then asked the developers to come up with a time bounded solution?

My guess: one of two things would have happened - the team would have arrived at a better solution or they would have found the same need for the original proposal. Either way everyone comes away feeling empowered and productive.

</comment><comment><USER30> Sounds like you should try really hard to:

1) Not hire someone that is going to argue about every single decision

2) Fire them if you get to the case of 1.

I have worked with quite a few "arguers" in my day. They all made good points. I am sure they were often right. But when it was 1v5 on the team for a particular decision, and our scrum master was making us having meetings for hours to resolve a stylistic difference that only 1 person agreed with.. blah. I cannot think of a better way to kill morale of an otherwise good team.

Sure in an ideal world, the team would work together and make decisions. If it's not working and one guy is sticking out over and over.. it's time to cut your losses. I have never seen a construction crew where one bricklayer would refuse to lay bricks a certain way, because he read a blog that another way is better. Sometimes you just need to put your head down and do the task, not make an argument about it.

<comment><USER31> > scrum master

Your development process is based on micro management...

> hours to resolve a stylistic difference

so it's not surprising that there are debates about the one thing the devs have control over.

<comment><USER30> Ya right, which is why I don't think in my own company I could ever see hiring a scrum master. I get the point in theory, and I have met a bunch of really great guys... but the process is just too much for my taste.

</comment></comment></comment><comment><USER32> In the military, leaders are taught to explain their guidance to subordinates whenever possible. But sometimes, a Soldier needs to just be quiet and roll out. Yes, this does require a Soldier to trust his leadership. It also requires them to be a professional. It is not your job as a subordinate to mentor/develop your supervisor. It is that team lead's supervisor. If I were treated this way, that subordinate would lose some of his paycheck or be forced to work many extra hours performing menial tasks.

Far more importantly, I would have lost respect for that individual. It's one thing to ask for clarification (which is awesome), it's another to convey blatant disrespect and unprofessionalism. No matter the circumstance or poor leadership, you do not demean yourself like that.

<comment><USER33> This isn't the military.

<comment><USER32> Thank you for the in-depth analysis buddy. It's a great how you addressed the underlying point of the comment.

<comment><USER33> Lol you sound like a shit boss/manager.

</comment></comment></comment></comment><comment><USER34> Really depends on how exactly was it said.

Option one: team member says "I think this is a bad decision". Should lead to a productive discussion, decision in the end taken by team leader. A person who cares about quality of a product and can argue for his point of view is a valuable team member.

Option two: team member says "I won't do it no matter what do you say because I don't respect your authority as a lead". Get it in writing, get paperwork done on termination due to insubordination (or whatever it's called in your country), so that every potential employer sees the red flag next time. A person who doesn't accept his role in a team and doesn't respect contract he signed (which usually specify chain of command) shouldn't work in the industry.

<comment><USER35> So, every bad team lead results in permanent blackballing of everybody they piss off? That's a dystopian nightmare.

<comment><USER34> If a team leader pisses you off and you think that they are inherently incompetent, you can tell it to his boss, and if it doesn't work, ask for a transfer to another team or resign. Telling him "I don't recognize your authority" is a _really_ bad way to react to such a situation.

<comment><USER35> People are human. These humans deserve better than draconian blackballing because it offends somebody.

</comment></comment></comment></comment><comment><USER36> Something tells me the other side of the story (told by the dev) would sound very different.

</comment><comment><USER37> > Lead: I need you to implement "X". > Teammate: No. > Lead: This is not a > choice. I am telling you to do this. > Teammate: You need to convince me.

There will be times, even as a junior team member when you strongly disagree with a decision. I have always felt that there is a virtually unlimited supply of people out there who can implement what they're told to implement, but that if I wanted to justify the salary I wanted it was my obligation to share my expertise by pushing back against what I saw as bad architectural decisions.

Early in my career, this didn't work out so well for me :)

I think I've figured it out by this point. There is a balance to be struck between "you're the boss" and "I don't think this is the right path" \- and that balance differs from person to person. There are some key factors that remain constant:

1\. It's not personal. I'm careful not to imply that something is wrong with the person who made the decision, merely that I disagree with the decision. If it feels like egos are getting involved - including my own! - I drop it

2\. Organizational structure exists for a reason. I'm very explicit in acknowledging that I will perform the task as given to the best of my abilities if that's what is asked of me.

3\. Keep it private. Challenging your team lead in a meeting with a half-dozen other developers is a Bad Idea.

Basically, I don't think it's too much to ask that your leadership treat your professional opinions with respect. If you are working in an environment where the above seems impossible to you... you should change your environment.

</comment><comment><USER38> The author is giving us zero contextual information. That is a red flag in and of itself.

The variable is a proxy for a deeper issue which the author is purposefully withholding.

</comment><comment><USER39> Key question: how are you going to handle things when you know you're right but the team/lead votes the other way?

Some folks, once they know what is right, will never do anything but that. Avoid these people. Some folks are so apathetic they agree to anything. Avoid these people too.

There's an old phrase "Strong opinions, lightly held". Have good and powerful reasons for the viewpoints you own. Defend them -- at length if necessary -- and passionately argue the merits of your view.

But at the same time, get a grip. Your job as a professional is to both have strong opinions about quality and to be able to dance to whatever song is playing. At some point, sure, the environment could be so bad that you should take a walk instead of staying and putting up with it. That's one of the values they hired you for. But whether or not to have a private variable is not that point.

ADD: I think this is just as important, _more important, actually_ for leads and managers as it is for workers. We model the behavior we want to see. If you're hard-headed and have a take-no-prisoners attitude, or if you're apathetic and jaded? Your reports see that. They copy it.

<comment><USER7> > Your job as a professional is to both have strong opinions about quality and > to be able to dance to whatever song is playing.

Yeah, this is really key. I have some very strong opinions about quality processes in software development. My employer and my team lead are paying for my expertise and advice, and I give it to them. But at the end of the day, if they want to pursue what I believe is an unwise course, I have a decision: follow, or resign. A professional doesn't spend his time sniping & griping: he knuckles down and produces — or he leaves.

We can't all be special snowflakes.

</comment></comment><comment><AUTHOR> As the author of the post. Just a couple comments...

1) I am referencing a team lead not myself. 2) I still agree that no one was right or wrong in this situation, and it had the right intentions to stir up discussion to see what people thought about it. 3) If you have reference to other posts that I have put on my site than you will see that as a leader you have to surround yourself with people who are better in certain or all verticals than you.

Check out this post ([https://www.softwareteamlead.com/lead-by-example- characteris...](https://www.softwareteamlead.com/lead-by-example- characteristics/)) on the characteristics I strive to exemplify.

</comment><comment><USER40> I am reminded of this: [http://edw519.posthaven.com/it-takes-6-days-to- change-1-line...](http://edw519.posthaven.com/it-takes-6-days-to- change-1-line-of-code)

But I also have the thought that in the military, the person issuing orders is also responsible for things if they go wrong. If his orders are bad, he takes the fall for them. I wonder if that is the case here. Or is it a case of "Do as you are told, and then take the fall when it breaks our system."

If so, you have deeper problems than one guy saying "Nope. No can do."

</comment><comment><USER41> From the article:

> He isn't a bad worker, but the relationship between the leadership style and > his work style are clashing.

If refusing to take orders doesn't make you a bad worker, then what does?

I've carried out orders that I didn't agree with many times. Disagreeing with your boss respectfully is a bit of an art, especially when the person who is likely to suffer from a bad decision is yourself. But at the end of the day, this is why we call it work instead of play.

One strategy that seems to work is: be diligent, get things done well and on time, and gain the trust and respect of your team and managers. People will listen to you more when they stop suspecting you of shirking work or just being argumentative. Instead of arguments, you can have conversations and sometimes you might even prevail.

<comment><USER3> It depends if you want "yes" men, or people to disagree with you. It might sting sometimes, but people who are willing to argue with you are much more beneficial to the organization for the most part. (I accept that some people just like to argue for the sake of personal satisfaction, I'm assuming this isn't the case here).

Remember, they aren't making widgets, they are engineering software; it's a high knowledge, high skill task.

<comment><USER42> >It might sting sometimes, but people who are willing to argue with you are much more beneficial to the organization for the most part.

>The thing about shit code is it costs 2x, 10x, 100x of technical debt later.

I'm on board with all those things, but bear in mind the insubordinate guy is alleged to just think it's 'bloat', not that he thought it would undermine the whole architecture of the code (and it's easy to imagine 1 additional class variable not doing so). Bloat is often a problem of autists.

<comment><USER3> Yes, that's a good point. The facts are scarce and it's hard to tell what's going on, so I can only make assumptions. I'm making assumptions based on my experience. If I bother to speak up about something, I think it's worth talking up about. Could it be the guy was just being a prick? Absolutely.

</comment></comment></comment></comment><comment><USER43> I had a chairman of a company scream that if we did all not do exactly as he said, he would consider it insubordination. I found another job, then sent him a private message to go fack himself.

</comment><comment><USER23> > Lead: This is not a choice. I am telling you to do this.

> Teammate: You need to convince me.

Lead: If you don't do it, you will be fired and replaced with someone who will. Convinced yet?

<comment><USER17> When you have to threaten someone on your team, you've reached rock-bottom as a manager; all you're really accomplishing is convincing your team to leave for greener pastures.

<comment><USER23> You know how Mao said power flows from the barrel of a gun? In the office, power flows from the threat of job loss. It's the threat implicit in _every_ executive decision.</comment></comment></comment>


Exploding Kittens by Elan Lee (and the Oatmeal) - jack-r-abbit https://www.kickstarter.com/projects/elanlee/exploding-kittens <comment><AUTHOR> I did not know Elan Lee [1] before this KS but it never ceases to amaze me the level of influence/buy-in that Matthew Inman managed to amass.

1: [http://en.wikipedia.org/wiki/Elan_Lee](http://en.wikipedia.org/wiki/Elan_Lee)

<comment> jack-r-abbit I think I read that the project was fully funded in only 8 minutes of going live. And within 7 hours it reached $1Miliion

He also managed to raise that insane amount to building a Tesla museum.

</comment></comment><comment><USER2> That's insane.</comment>


Self-control need a boost? Gargle sugar water, researchers say - <AUTHOR> http://www.boston.com/lifestyle/health/2012/11/09/self-control-need-boost-gargle-sugar-water-researchers-say/4Fw3dY48OJNUmSgrSNU0pI/story.html <comment><USER2> Tip: weak green tea with sugar (or white or black tea if it's more to your taste) - the added low dose theanine and caffeine amplify the benefits of low dose sugar (assuming you're not already ODing on coffee or other caffeinated thing) ...sipping it slowly while slogging through some "hard to swallow" but attention demanding task does wonders.

</comment><comment><USER3> Don't do this if you value your teeth (or maybe rinse out after).

</comment><comment><USER4> Sounds like a plug for sugared chewing gum.

</comment><comment><USER5> I guess that explains all the soda cans around my room after a long coding session.

</comment><comment><USER6> I wonder what effect this will have on your teeth over time. Any insight?

</comment><comment><USER7> Does it need to be gargled? If I'm following the reasoning of the article correctly, simply consuming sugary food should have the same effect. Am I misunderstanding?

<comment><USER8> That consuming small amounts of sugar regularly boosts motivation and willpower has been known for a long time, but as the article says the assumption has been that this is due to the actual intake of sugar. What they are saying is that they think their results may show that simply _tasting_ the sugar is sufficient.

(But I wonder if they controlled for whatever amounts of sugar subjects might inadvertently get in them anyway while gargling)

<comment><USER9> "Because participants did not ingest the glucose, they could not have absorbed a significant amount of it into their bloodstream. Moreover, it takes glucose 10 to 15 min to enter the brain after ingestion (Zourek, Jankovec, & Hykova, 2011)."

</comment></comment></comment><comment><USER10> How is performing faster on a tedious task related to self-control? Shouldn't that be "improve focus" or "improve concentration"?

<comment><USER11> Elective control of concentration _is_ self control.

<comment><USER12> (Possibly naive question) Is that considered strictly _elective_ control? I mean, I suppose I can assume I will always have access to sugar water so I'm electing to trick my body.

</comment></comment></comment><comment><USER13> Isn't gargling sugar still consuming sugar? Digestion of simple carbohydrates begins in the mouth with saliva.

<comment><USER14> No, they get broken down, but do not enter the bloodstream. The sugar molecules bind to receptors to give you the sweet taste.

</comment></comment><comment><USER15> If gargling XYZ is too fussy, An apple works.

</comment><comment><USER16> Self-control need a stall? Gargle artificially-sweetened water, researchers say.

Sorry, the article is behind a pay wall. The summary does nothing to impress me.</comment>


The Kafkaesque Battle of Soulseek and PayPal - <AUTHOR> https://www.eff.org/deeplinks/2016/02/kafkaesque-battle-soulseek-and-paypal-and-why-free-speech-defenders-should-be <comment><USER2> Paypal and Kafkaesque in the same sentence don't come as a surprise, but I _am_ shocked that Soulseek is still a thing.

<comment><USER3> Soulseek is still really useful, especially after the crackdown on Megaupload/Mediafire/Rapidshare.

For niche and obscure music, it's always been superior to torrenting IMO.

<comment><USER4> You mean out-of-copyright music, or music being shared by the copyright holders, right?

<comment><USER5> I understand what you're saying but there are also lots of instances where you simply cannot find something for sale anywhere and sometimes I simply don't mind flouting copyright rules if it's the only way to locate a copy.

Trust me, I've purchased plenty of used CDs or other formats on eBay or Amazon and will gladly do so again rather than bother with the hunt on Soulseek or other sources of unlicensed downloads. But in the end, as "entitled" as it may make me, I'd rather resort to copyright infringement than never find a copy of that (song/album/etc) from the tape or CD I lost in college that's just not available anymore.

</comment></comment></comment></comment><comment><USER6> Glad they mention Bitcoin in the article. Bitcoin, as long as it trends towards decentralization and not away from it [1], eliminates these problems in the long run.

[1]: [https://bitcointalk.org/?topic=923.0](https://bitcointalk.org/?topic=923.0)

<comment><USER7> What's funny is in the article they are saying "many of the Bitcoin payment service providers, are bound by their agreements to Visa and MasterCard", in reality though you don't need a payment provider to send bitcoin to anyone and to top that off - the use case we're looking at here which is "donations" is perfectly fitted for bitcoin, you just provide your address on your site for ppl to send coin to and you're done.

Where bitcoin payment providers come into play is when a company is taking bitcoin as a method of payment for their goods and services which is not the case here.

</comment></comment><comment><USER8> dammit, first rule of soulseek is

<comment><USER9> haha, yes it was a bit of a underground thing.

From 2002 to 2006 I was listening mostly JRock only.

First we used Kazaa to get the music, since it wasn't sold in my country.

Later most people switched to Soulseek.

Was pretty nice... a bit like IRC. Only that the chat was rather bad.

Also the global search sucked, so you had to browse every person in the chat yourself.

But this made it also a bit more social, hehe.

<comment><USER5> My favorite was always Audiogalaxy but yeah, Soulseek really filled a niche before you could find a lot of stuff legally on Amazon or even eBay if it wasn't sold in stores.

</comment></comment></comment><comment><USER10> PayPal still exists?

</comment><comment><USER11> Haven't used Soulseek in years. Mac client... Love it.</comment>


How to improve your typing skills? - <AUTHOR> http://viptechworld.blogspot.com/2016/12/free-websites-to-improve-typing.html <comment><USER2> I made a typing game like these in Elm. It was just a fun little project to work on: [https://benjaminjosephw.github.io/typing- game/](https://benjaminjosephw.github.io/typing-game/)

<comment><AUTHOR> I tried it but i'm confused what i have to do in the game?</comment></comment>


Ask HN: What are some good developer portfolios? - <AUTHOR>

I'm setting up a personal website and want to include a portfolio page to showcase the work I've done.  Does anyone have any good examples of portfolio pages for developers?  I'd like to look through some to gather ideas for setting up mine.
I've come across this one - http://thinkcage.com/portfolio/ - but he is a designer, not a developer.
Feel free to promote your own. <comment><USER2> I just show my github page.</comment>


Ask HN: What are the books to learn the hacker culture? - <AUTHOR> What are the books to learn the hacker culture? What is the best for you?<p>I know there is "Hacking: The Art of Exploitation" by Jon Erickson but the last edition was in 2008. <comment><USER2> Although its not a book, Eric Raymond's essay "How To Become a Hacker" is my favorite read on the subject: [http://www.catb.org/esr/faqs/hacker- howto.html](http://www.catb.org/esr/faqs/hacker-howto.html)

<comment><AUTHOR> Thank you for this reference.

</comment></comment><comment><USER3> The hacker culture itself is just a movement that embodies the principles one would naturally grow once one fully immerses oneself in an intellectual pursuit such as computer programming, model train hacking, math, lock-picking etc. Hence you don't 'have' to learn the culture from some damn book

<comment><USER4> Cultures are complex things; encompassing, amongst others, habits of thought, a common vocabulary, shared values, a sense of group history, and so on. The hacker culture is indeed quite heavily defined by its ways of thinking and shared values, which don't need to be learned from "some damn book". However, all the other aspects that together constitute a culture do need to be picked up from other members of said culture - and with a culture as distributed as hackerdom, that would indeed be best done by reading books.

</comment></comment><comment><USER4> To understand the hacker culture, you must understand its background and history. Here are some good books:

"The Jargon File", Eric S. Raymond (ed.) [http://www.catb.org/jargon/](http://www.catb.org/jargon/)

"The Cuckoo's Egg", Cliff Stoll

"Hackers: Heroes of the Computer Revolution", Steven Levy

"Where Wizards Stay up Late", Katie Hafner

<comment><USER5> I'd also suggest "the innovators", Walter Isaacson, on top of those.

</comment></comment><comment><USER6> Not a book, but view «Project Code Rush»

[https://www.youtube.com/watch?v=4Q7FTjhvZ7Y](https://www.youtube.com/watch?v=4Q7FTjhvZ7Y)

</comment><comment><USER7> I'd say the culture classic is the Hacker's Manifesto by The Mentor, published in Phrack 7.

[http://phrack.org/issues/7/3.html#article](http://phrack.org/issues/7/3.html#article)

<comment><USER8> That was a cringy, painful read.

</comment></comment><comment><USER9> Kevin Mitnick's "The Art of Deception" comes to mind. While it's more the black hat type, it's a good look at social engineering from the perspective of an expert. I'm always intrigued at how a lot of hackers start with an interest in magic tricks.

</comment><comment><USER10> I'd suggest listening to the Sex Pistols and Operation Ivy.

Yes that's punk music. I think the cusltures are similar and have similar ideological roots.

Maybe you're asking about hacker skills. Of course punk music won't teach you hacking skills.

<comment><AUTHOR> Yes, it's not hacker skills but thank you for the hacker culture.</comment></comment>