Russia Pulls Space Cooperation in Response to Ukraine Sanctions - <AUTHOR> http://www.newsweek.com/russia-pulls-space-cooperation-response-ukraine-sanctions-250869?piano_t=1 <comment><USER2> I think, this is a great opportunity for Elon Musk to make his place permanent in the space supplies sector and for privatization of space sector. I would be really looking forward to how things will turn out for him. I'm not a fan of him, but just say.. I'm interested in his work.

Though, reliability and espionage-possibility would remain a concern.

</comment><comment><USER3> Well needless to say this is good news for SpaceX which will probably accelerate their plans for a dragon capsule that can carry passengers.

</comment><comment><USER4> First step in annexing the ISS. Wasn't entirely unexpected but seems like a poor long term move on Putin's part.

</comment><comment><USER5> That's sad that all this dirty politics affects the fun of exploring space

<comment><USER6> Being of strategic value, space was political from day one. Nothing ever done in space was entirely apolitical. AAMOF, there would be _no exploration_ at all without politics. So get used to it.

<comment><USER7> So, the beatings will continue until morale improves? Is that the best offer you got?

Fucking hell. No wonder this world ain't worth saving.

<comment><USER6> You don't understand my point. If you look at human psychology, things connected to power are often fascinating, but not always in the "I'm going to get the other guy and beat the shit of him" way. Young boys are fascinated with toy helicopters, trucks, army soldiers, and yes, spaceships, but they aren't being evil/scheming about it. For them, it's just a game. There are two levels of fascination with power: a) the childish "ooh that's cool" and b) the adult "hmm, we would be a pretty powerful nation/team/individuals if we got hold of it".

But the underlying reason why something is fascinating -- because it is connected with power -- doesn't change. So it is hypocritical to claim that "I want this and that, and my intention are innocent and sincere" when the object of your desire is a helicopter gunship. Now, something flying at 7.8 km per second is potentially far more dangerous than a helicopter gunship.

In other words, wanting space exploration to be free of politics is essentially wanting power to be free of politics. Which is a bit oxymoronic. As soon as your exploration produces something interesting, be it knowledge, materials, or even location, someone else is going to want it for themselves.

</comment></comment></comment></comment><comment><USER8> Sanctions with a country as large as Russia are defiantly a two way street.

Sometimes people appear to forget this during talk about handing them out.

<comment><USER9> I don't think anybody forgot that at all.

The bet is that Russia's economy is so much smaller now in relation to the other economic giants, as compared to the cold war days, that the ability for the US and EU to hurt Russia is greater than Russia's ability to cause damage back the other way, by a substantial factor.

The US economy by itself is eight times the size of Russia's. Europe has four economies as big as Russia's. Canada and Australia now have economies nearly on par with Russia's.

Russia only has one real trick up its sleeve, and that's natural gas. They can act on that, but it'll cripple their own domestic economy and send the oligarchs into a fit, which risks Putin's power.

For emphasis:

US + UK + Germany + Italy + Spain + France + Canada + Australia = $32 trillion in GDP give or take. Russia = $2 trillion. It's obvious who will win a battle of sanctions. Not to mention the ruble can fairly easily be crushed by the dollar hegemony.

<comment><USER8> I'm not saying the west won't win.

I'm just saying don't forget the cost. And incidentally, I'm not entirely convinced that paper wealth trumps natural resources in today's world.

Also, I wouldn't count on Russia having only "one trick up it's sleeve".

</comment></comment></comment><comment><USER10> SpaceX will be happy.

</comment><comment><USER11> Well good luck to Russia, totalitarian fascism would work out great I am sure. There would be millions of Russians spinning in their graves if they knew of what the "motherland" has become.

<comment><USER12> On the other hand, Edward Snowden is quite happy about it... at least, happier than seeing what the US has become.

<comment><USER13> Which means what? Presumably Snowden would be happy anywhere he isn't being arrested and extradited back to the US.

<comment><USER12> And where else is that, except in Russia? Possibly maybe in some South American countries, if only he could get there...

</comment></comment></comment></comment><comment><USER14> It's a shame that science, which often bridges political divides, has to suffer due to political bullshit. Somewhat understandable given the history of space exploration, but bullshit nonetheless.

It also makes Russia look like a petulant child, taking its ball and going home because it didn't get to eat another child's chocolate.

<comment><USER15> This is only Russia refusing to sell rocket engines to the US Government for use in launching military rockets into space. This has nothing to do with the scientific collaboration.

<comment><USER16> I'd call not continuing ISS beyond 2020, when according to NASA there is no technical reason that it could not operate until at least 2028 to be a blow for scientific collaboration.

<comment><USER15> The grandparent post is sounding like the Russians are stopping immediate collaboration as a result of the Ukrainian conflict. That is not the case, and it is not clear if the ISS issue is even related to the situation at hand.</comment></comment></comment></comment>


Why your programmers just want to code - <AUTHOR> https://medium.com/maker-to-manager/why-your-programmers-just-want-to-code-36da9973388e <comment><USER3> A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you help me? I promised my friend I would meet him half an hour ago, but I don't know where I am."

The man below says: "Yes. You are in a hot air balloon, hovering approximately 30 feet above this field. You are between 40 and 42 degrees N. latitude, and between 58 and 60 degrees W. longitude."

"You must be an engineer," says the balloonist.

"I am," replies the man. "How did you know?"

"Well," says the balloonist, "everything you have told me is technically correct, but I have no idea what to make of your information, and the fact is I am still lost.

"The man below says, "You must be a manager."

"I am," replies the balloonist, "but how did you know?"

"Well," says the man, "you don't know where you are, or where you are going. You have made a promise which you have no idea how to keep, and you expect me to solve your problem. The fact is you are in the exact same position you were in before we met, but now it is somehow my fault."

\--

This is the sentiment that I see in the article.

It reads like someone who is not a software engineer criticizing software engineers because they don't do what he wants. Sure there is a reference to culture and that. But, ultimately, he wants software engineers to care about business and market issues over software issues. He sees the software engineer as an impediment to the problems he is trying to solve rather than someone who tries to contribute through his domain of expertise. This situation is not going to change by using the amateur psychology of not rejecting an engineers ideas when they are starting out. That is insulting and, frankly, the heart of the problem -- that he sees software engineers as children to be led rather than peers who you can collaborate with.

<comment><USER4> _his "team-friendly" interactions were usually sarcastic. He often talked about technical debt, our lack of innovation, and the "stupid" decisions holding us back. An irritating "I told you so" sentiment plagued his comments and feedback._

The easily missed point here is that Jamie, on some level, still cares. The ones this author doesn't recognize are the ones who don't give any outward sign of annoyance, because they genuinely don't care. They'll participate in your "chaos is a process" and roll with your shifting requirements by doing the bare minimum at all times. Maybe they'll throw in some stuff occasionally to wow everyone, usually not. They'll just plug along, keeping their ideas and improvements to themselvse, watching you fail. Because they've seen this all before. Rare is the organization that knows what they want, and have structures in place to effectively build and grow products. I've personally seen it exactly once.

<comment><USER5> > I've personally seen it exactly once.

I've seen it twice.

I left the first company where I saw it (I stayed for 6 years and learned more here than everywhere else else combined, despite the other problems) because despite having all of these brilliant people and alignment with front-line managers and other teams and strong process and strong product guidance the company was ruled over by a tyrant in the CEO and CFO. The CFO only cared about the bottom line and the CEO, too, but he cared more about taking full credit for all of our engineering successes. The folks I kept in contact with say not much has changed but that they've brought in some MBA types in the form of senior managers and things have been doing downhill since.

The second time, I came in to the organization and it wasn't great but things worked and we were solving real problems for real people and for some reason it clicked well between the different groups/departments. Then the CEO and board, in their eternal quest to go IPO, disrupted the Engineering upper management chain, and we went through 3 different CTOs in the span of about 16 months. Suffice it to say, the magic was lost. That company is _still trying_ to go IPO, of course, and _still thinks_ they'll achieve it by bringing in different executive management players, last I heard.

</comment></comment></comment><comment><USER6> > _His concern for market share and business health is replaced with (...)_

> _His enthusiasm for changing the world is replaced with nit-picking the > development process._

Here's your answer. It's because you hired the programmer based on technical competence and not their attitude to servitude in business.

You get what you measure. You didn't disqualify me as a candidate because I think your business is boring and I need the money. So don't be surprised that I'll be doing my job as effectively as possible - which involves lots of lone coding, unless your internal process is completely bonkers - but I ain't gonna drink the kool-aid. Want someone with a more "professional" attitude? _Filter for that during the interview_.

And that "changing the world" thing? That's just bullshit, and you're not fooling anyone past their teenage years with that. You're not SpaceX. You're not changing shit. Chances are, you're just trying to make money selling the usual butt CRUD everyone else is selling too. If you hire smart people, don't be surprised they know it's bullshit.

Programmers want to code because they're programmers. Chefs want to cook because they're chefs. That's what they do. This article only shows hiring laziness, coupled with usual complaining that the company isn't getting more than it asked for.

\--

EDIT:

Ok, this article doesn't _only_ show hiring laziness. The point about how vulnerable enthusiastic people are in the initial period is spot-on and I agree with it. I wrote the above comment because I believe that the article as a whole exemplifies additional lack of understanding of the perspective of programmers, which can lead to extra post-interview disappointment.

<comment><USER7> _> You didn't disqualify me as a candidate because I think your business is boring_

Er, I suspect this would make it impossible to staff 90% of positions in programming. If I thought a business were exciting, I would be a specialist in that business, not in programming - or I'd be a very lousy 9-to-5 programmer, because my passion lies elsewhere.

Very few companies have the luxury of hiring passionate programmers who are also interested in making the business succeed; most of them just want their payroll system chugging along and someone to sort out their Excel when it breaks.

<comment><USER6> > _Er, I suspect this would make it impossible to staff 90% of positions in > programming_

Well, of course. So a typical company with a boring business[0] shouldn't expect that people they hire will suddenly develop deep love towards the company and the business it's in.

> _Very few companies have the luxury of hiring passionate programmers who are > also interested in making the business succeed._

Exactly. Very few companies _need_ that luxury, too. That's why I'm saying this article is an example of complaining about not getting more than one should be getting. When you hire someone to do the job right, you require them to do the job right[1]. Asking them to behave like a co-founder, except without equity and any decisionmaking capability, is a bit much.

\--

[0] - I'm not saying "not important". Driving a garbage truck or managing payroll data are examples of jobs that are boring, that don't "change the world" by themselves, but are nonetheless very important - each instance of such a job is a crucial thing for a segment of society that benefits from it directly.

[1] - And in our industry, that does involve letting them run some of the show. When you hire an expensive specialist, you do that because they have the knowledge and experience you don't have (or don't have time to use yourself).

</comment></comment></comment><comment><USER8> The programmer in this story has realised this fundamental truth:

The spoken word is ephemeral and easily forgot. The design of the product that pays the bills is not so easily undone.

What people say in meetings; all the posturing and preening; the petty one- upmanship and power-play — none of this has any relevance to what actually gets done in the real world.

When it comes to what actually gets implemented — all of the power is in the hands of the programmer who gets there first. After all — once the die has been cast and the direction set, who is going to undo the work and start again?

In this, the programmer is the decider.

Programmers have an immense amount of power, and there is no reason whatsoever why he shouldn't simply ignore the pointless social preening and get on and make the product that he wants to.

After all, the consequences of his decisions will ripple far and wide thorough the product and beyond and have a heft; a level of consequence and a permanence that no 'soft' skills specialist can match.

<comment><USER9> A healthy team is a team with high social capital: a team that seeks the common good, where people clean up after themselves and volunteer to help others. Everyone wants the best idea to prevail. All this while preserving critical thinking and trusting other people with the feedback that is necessary to improve. Their most important competitor is another company.

An unhealthy team is a team with low social capital: a team that seeks individual gain and people force others to pick up after their technical debt. Everyone wants their own idea to prevail. All this while avoiding any form of uneasy conversation and withholding feedback. Their most important competitor is each other.

<comment><USER10> Absolutely! And I've seen companies with reward structures that focus on individual performance cause a lot of these unhealthy teams to arise unwittingly.

</comment></comment></comment><comment><USER11> After you have a good decade of experience under your belt, most programming is... easy. Sure maybe not if you're working on self driving cars or game engines or kernel modules, but then the programming is only half the point anyway - the rest is math and science.

But if you're not working on one of those but doing something more typical, and you're decently experienced and competent (and maybe also not compulsively chasing the bleeding edge), then programming is often just cranking out features, a steady drip of success. So of course the path of maximum pleasure is to crank out code.

What's harder than coding? Smartly balancing the stakeholders. Maintaining the discipline, motivation, and knowhow required to maintain the engineering process - testing, documentation, CI, etc. Herding the cats that are a group of programmers, managing the egos, ensuring that a team stays aligned on style and architecture, that's the hard stuff.

<comment><USER12> The problem many programmers face, is that for the issues you mention soft skills are a must have.

So of course, some find it easier just to code away without having to deal with other humans.

Personally, I get bored to death on the projects where I happen to be a lone dev.

<comment><USER13> > ...for the issues you mention soft skills are a must have...

Only because technical decision making is poorly structured in most organizations. Or it's clear but evaluation of decisions and decision-makers is poor.

If it were:

\- get feedback from these N<3 people \- here's how you do that \- they are required to give clear decisions \- within X days

...it wouldn't matter so much that Engineer McCodeface wasn't the best at attending happy hours, back-scratching, etc.

<comment><USER14> This only works if your organization actually hired at a certain minimum level of competency from EngineerMcCodeface[1..100]. In a hospital interns opinions do not carry the weight of residents, residents opinions do not carry weight of the attendings, and attending opinions do not carry weight of a Chief of Surgery.

<comment><USER13> Also a good point.

</comment></comment></comment></comment></comment><comment><USER9> How would you feel if:

\- you were a chef. you went to culinary school and know about cooking and best practices.

\- you are asked to forget everything you learned in school and flip burgers with overly reused oil and unwashed equipment.

\- you are told that there's no time to clean the kitchen, or wash your hands. just flip as many burgers as possible to maximize profit.

\- the ones that cook the most burgers are rewarded, treated well, promoted. as soon as cooks realize this, they start making half-cooked burgers that make people sick.

\- the customers get sick all the time from the lack of hygiene. you talk about it, and you are told to keep doing what you are doing, or that you don't understand what being a chef is, or what the business is.

\- in the end the only source of gratification is getting a paycheck, or doing something in your spare time. you are not cooking real food, just part of a machine that makes money for a self-serving company while ripping off the customer.

This is what it feels to be an engineer in many companies.

<comment><USER15> You always have a choice.

<comment><USER12> Depends where on the globe one is living.

It isn't always easy to switch jobs.

</comment></comment></comment><comment><USER16> >But, two years later, Jamie was "that guy". You know, the one who wants to code without being bothered.

>I should have noticed the signs. He didn't speak up in retrospectives, he didn't contribute process or product ideas like I expected, and his "team- friendly" interactions were usually sarcastic. He often talked about technical debt, our lack of innovation, and the "stupid" decisions holding us back.

I suspect if you just gave Jamie free reign to spend most (not all, just most) of his time refactoring the code base and fixing up the dev tooling while other people worked on bugs and features then Jamie would be happier, the code base would be less buggy and the other developers would get their features done quicker.

The fact that Jamie is quite grumpy about all of this suggests that the code quality and tooling at this company is poor and he isn't being allowed to fix the things that are causing him pain.

And maybe he doesn't want to meet customers? Is it so bad if that task is left to somebody who _likes_ doing it?

>His enthusiasm for changing the world is replaced with nit-picking the development process.

>Worse of all, though, his concern that "We aren't building the right thing" will be replaced with "We aren't building the thing right."

This attitude absolutely floors me. You absolutely want a diversity of attitudes and skills on any team and that _includes_ having some people who worry more about building the right thing and other people who worry more about building the thing right. Those are complementary attitudes that usually go with complementary skillsets.

<comment><USER17> You said something that reach me so much: "tooling".

I sometime feels like if you don't have good tools, it's almost impossible for the employees to be productive or motivated.

I often see some people working in the most unproductive way possible (to my eyes) that it actually discourage me. I'm left wondering how they can even get anything done when spending so much time doing simple tasks.

<comment><USER16> Yeah, I sometimes joke that the average developer is a somebody who pushes their code with a series of repetitive git commands typed in unreliably, deploys unreliably with a repetitive set of shell commands, relies almost totally on a battery of bored, robotically clicking manual testers and believes that he is automating people out of a job.

I think one of the most underrated (and almost totally ignored) parts of the mythical man month was the notion of the toolsmith being a dedicated member of a good software team _who doesn 't work on features_.

</comment></comment></comment><comment><USER18> This is so on point:

"Culture isn't the slogan on your wall, or how you describe your mission during an interview. Culture is the way people actually act, and what they actually care about."

PMs and Dev Managers, your engineers are smart, dynamic individuals. If you engage them and include them in important conversations and actively solicit their feedback while providing context and customer feedback, you will get innovative and creative ideas, you will get an energized work force, and everybody will be happier for it. Don't treat engineers like an assembly line: software is a dynamic machine and it requires everyone's best work to evolve in the right way.

<comment><USER19> While you're not wrong about culture is action, here's studies show collecting and disseminating that culture (aka writing it on the wall - <USER2> management in the literature) leads to measurable competitive advantage.

Sorry these are from journals

[https://www.scopus.com/record/display.uri?eid=2-s2.0-7795302...](https://www.scopus.com/record/display.uri?eid=2-s2.0-77953027877&doi=10.1016%2fj.jbusres.2009.06.005&origin=inward&txGid=00233ff082dcf44d5150557779b268f7)

[https://www.scopus.com/record/display.uri?eid=2-s2.0-8005505...](https://www.scopus.com/record/display.uri?eid=2-s2.0-80055059599&doi=10.1108%2f02580541111177548&origin=inward&txGid=d8b8914e2770bda839307aab61e242fd)

</comment></comment><comment><USER20> 3 years ago I crossed the ocean to join a team on a project that seemed great.

I'm not 25 anymore so it was a big deal, moving my wife and kids (but it's on a Caribbean island, so they were not hard to convince).

I was asked to join because of my background in mathematics, my vision on resolving problems, and my programming skills.

Not bragging, I'm just a regular guy, but the person recruiting me was the co founder of my company, we know each other for 25 years. So he knows me well and know my skills. I was asked to join for bringing a new vision on some tricky points.

Small team, one leader.

Almost every time I proposed something new, it was dismissed, and sometimes with contempt.

Of course it's something they worked on for several years, and they tried a lot of solutions before I joined, so some of my idea were surely already tested and all.

But I ended up doing some UI on jquery (yeah, I know...) and became miserable as time passed.

Because, you know, before even be sure that the core was working, they wanted a fancy interface...

Ended bad. I finally quit after 18 months of doing the same stuff again and again, as the UI changed every time a new idea came up.

My point is I totally understand the point of the article. I came with a bag full of ideas and happiness on working on that. I ended doing shitty stuff and feeling uninterested and bored about programming shit all day.

</comment><comment><USER21> This hits a little too close to home for me.

I cannot count the number of times per that one of the following situations has happened:

\- I go to our designers with an inconsistency, omission or even an outright contradiction in the design just to hear that this is how it was designed and that the client approved this design, so we should implement it precisely as the design says.

\- Development is slowed down/held back by technical debt and odd implementation choices. When I suggest we fix this, I get told that fixing what isn't broken doesn't earn us money, so I should work around it for now.

\- I have a suggestion for some process improvement (for example: developer post-mortems, including developers in the design review process), to get told that it's already been tried at some point in the past (usually back in the really early days of the company when there were less than 5 employees) and that it didn't work back then, which means that it will never work, no matter how much has changed since then.

<comment><USER22> > including developers in the design review process

I was banging this drum for 2 years at my previous employer. I was always told it's a great idea but the people who knew projects were coming down the line just never reached out to the tech team.

We are all tech consumers, letting the design team work exclusively with the client is a great way to build the wrong product/features or over/underestimate the art of the possible.

<comment><USER21> > letting the design team work exclusively with the client is a great way to > build the wrong product/features or over/underestimate the art of the > possible.

Pretty much this. We consistently get screwed over on our schedules because designers just throw a design over our way without asking us for any input along the way.

</comment></comment></comment><comment><USER23> "It's only natural, then, that your programmer is reduced to doing only what brings him success: coding."

Replacing "success" by "pleasure" quickly reveals why there's not a single sentence in that article I can agree with. I for one am quite happy not being included in matters that sound like a different job title to me...

<comment><USER24> Oh, wow. Care to elaborate? I found the entire article so relatable that I even thought about registering on Medium to be able to clap.

<comment><USER23> I spent most of my day coding. Except for some fresh air breaks and occasional discussions on how to collaborate I actually spend every second doing it. And I love it. The article suggests in its whole premise that this is wrong. For me and for the business. Yet it lacks any evidence on why I should want to do more than that - in fact I would even call it blindly dogmatic in that regard.

But at least in my work context I think that my boss's job is to keep me from customers and design decisions as much as possible - since that is what I love and what yields the most productive use of my time. I wonder why my joiner friends aren't told that spending all day in their workshop creating beautiful wooden art is wrong and that they should instead derive more pleasure from interactions with their customers...

Maybe in an ideal world someone who cries over every line of code since she/he would much rather make design decisions but is left out of the creativity loop just isn't a natural coder. Just like someone who hates working with wood maybe shouldn't.

I am well aware that this is a position of extremes and blocks out the gray areas that are reality. But _my_ work reality is just not what this "Hacker, Problem Solver, Calvinist, Geek" regards as the very premise of his manager lesson.

<comment><USER19> Does it not bring you any pleasure for your users to find your work valuable ?

We could all just sit at home and write code all day. but without users there is no point.

The situation describe in the OP is a result of a poor management culture, which is why it's there.

<comment><USER25> > We could all just sit at home and write code all day. but without users > there is no point.

Depends on how you are motivated. Speaking for myself, my motivation always comes from myself, never from what others think of my work. The users/paying customers aren't the point, at best they are an enabler, allowing me to spend more time coding that I would otherwise have to waste by having a non-coding job.

<comment><USER19> I do totally understand that motivation, coding is enjoyable. I have lots of code on github that I wrote that no-one has ever run since the time I checked it in once it worked.

But the PHP code I wrote that was getting 1m pageviews a month gave more of a sense of achievement than my clever raytracer.

</comment></comment></comment></comment></comment></comment><comment><USER26> I just realized that I turned into Jamie sometimes as well.

At the beginning of a project, I worked without respect to boundaries. When a bug in another teams codebase held me back, I fixed it there. Over time I learned that this was neither appreciated nor welcome for some, so I stopped doing it. Unfortunately, this also a problem for me, because the bugs don't get fixed and block me.

I invited a programmer from another team into my repo and we collaborated there. Then I was told not to do the work for another team (by the other team, ironically), so we forked. Now the repos have diverged and the users, who want to use both, suffer.

</comment><comment><USER27> "He often talked about technical debt, our lack of innovation, and the "stupid" decisions holding us back. An irritating "I told you so" sentiment plagued his comments and feedback." I recognise myself very much in this traits. When I work on a new project, I maintain a diary with a section todo and a section technical debt. It appears, there are always many items in technical debt.

The mindset of people is very influenced by their role. A developer is mainly fixing bugs and creating architecture that should be less bug prone. Anticipating problems is our job and does not mean we are negative. We are happy when the technical debt is small. I think that this article shows that people have difficulties to listen to developers and do not grasp their mindset. I am quite happy my boss listen to me. In a previous job, I had a colleague who helped me a lot to get listened to.

I think a developer needs to have good stretches of time undisturbed to get work done, but needs to spend time discussing with others to understand their needs and provide his insights. If nobody listen, the developer can only complain like in this article.

<comment><USER28> I agree. I imagine the beginning of the end is, the agile standup/sprint process. Instead of addressing the code as a whole, we're reduced to picking at one piece at a time in isolation. No development without a customer issue to justify it! Especially the new guy.

And to come in after a couple of years of this, and find a code base that is a pile of individual pieces in a loose spaghetti wad, is so absolutely disillusioning. You want to fix it; you know what needs to be done; but you have to add this field to this structure so some UI element can report some crap that hardly anybody cares about instead.

<comment><USER29> Just realized this is now me. "A pile of individual pieces in a loose spaghetti wad" exactly describes what I've been made responsible for. Each source file shows scars of sprints where some poor fool was given a story and told "just make it work" with no concern for any big picture.

<comment><USER28> I'm so sorry! btw like the imagery 'shows scars of sprints' \- well said

</comment></comment></comment></comment><comment><USER30> There is a huge amount of insight on this post and I could not upvote this story enough. It is exactly the onboarding process and all the BS/political powerplay and non-productive rhetorics that pass that exact message to a programmer. Multiply this by ten if you happen to be a non-native developer in a mostly ethnic company where your language skills are below native. So -even though it is never clearly said in the open- the message gets to be 'you are just a "foreign" code monkey'.

</comment><comment><USER31> Wow. This article really resonated with me. I was "Jamie" until 2 months ago.

I choose my jobs very carefully. So when this company had a reputation of hiring the best, I was beyond excited. The interview process was great. I really liked interacting with the (future) manager.

And....things went downhill in the very first month. In the first team meeting VP announced that the manager was moving on. All the while I could see it was not mutual agreement between the manager and VP. But, I thought that was not my problem.

A meeting was set with the new manager and there it dawned to me that I was in huge trouble. The new guy wanted me to do a presentation in front of the VP and other C-level executives. "But I am not aware of the project requirements" I said. He summarily ignored my objections.

On landing in front of the VP and C-level people I was criticised for not knowing the project requirements. While the old manager tried to help me, the new guy kept his mouth shut.

Later the new manager offered me a half ass apology. That proved to be the last straw and I became the person who just wanted to code.

</comment><comment><USER32> > Worse of all, though, his concern that "We aren't building the right thing" > will be replaced with "We aren't building the thing right."

Oh man, this one hits very close to home.

I can say there exists at least one additional circle of hell, found after the engineer has abandoned all hope of influencing code-quality. The kind found after executives have hired outsourced teams to "help" add features with no code-review process or commit-hooks.

Perhaps: "We aren't logging errors right."

</comment><comment><USER33> As someone who has been programmer and now hires lots of programmers, there are things in life you can't buy, like love, or in this case, respect.

I learned motorola assembler, then intel's when I was a kid and have been programming all my life,studied engineering and made a software company from scratch.

Programmers respect me in a way they do not respect an MBA, no matter the title or the money they have. In a company it is a big problem.

You can't see it, it is invisible but man you could sense it, it is a very strong force.

</comment><comment><USER34> This article comes to entirely the wrong conclusion, and I am _very_ encouraged at the number of commenters pointing it out.

Engineers engineer. They are highly trained professionals who are doing their job when they are figuring out how to build something, improve something, or fix something, often with the goal of being able to develop new features quickly without an inordinate number of bugs.

Your engineering team shouldn't be running your business. Even if they have good ideas. And in practice, they will be overruled immediately, anyway, the moment someone with any real authority makes a roadmap or a key decision, because they are engineers. They aren't answerable to the board. They haven't studied the market and competitive landscape in depth. They can't pivot the company.

There's something perverse and The Office-like about diagnosing Jamie as a problem "but it's not his fault."

Engineer runs into boss's office: "Sir, code quality is critically low. I suggest we begin paying down technical debt before it's too late." Boss, smiling to camera: "This is Jamie. When he started, he was a team player. He believed in the vision. He didn't spend all day nit-picking about things like code quality. Look at him now! I don't blame Jamie, though. I blame myself. If I had made Jamie feel like his big ideas and product insights were welcome here, early on, he wouldn't have devolved into seeing himself as a mere code monkey."

</comment><comment><USER35> Yet another person who I feel I would dislike working with. Maybe, at the start of each post where people ramble in such a binary fashion, they could post a snippet of why they think they can comment with authority on whatever the article content is about.

This guys MO ties in nicely with most "well meaning" but utterly clueless folk I've seen when it comes to software development.

Even more so when I see his site ([https://marcusblankenship.com](https://marcusblankenship.com)) has:

> Let me teach you how to create a high-performing software team

</comment><comment> ju-st I think managers begin to BS around and only caring about paychecks for similar reasons. It's not only the lowest level in companies (programmers, engineers...) who grow tired of non cooperating higher ups.

</comment><comment><USER36> So there are two stages here... First is caring about the what, and getting no traction in determining that. It's left to the PMs. Second is caring about the how, trying to at least get ideas implemented on that front. But what's the stage after that? If you get no traction on making a better what, nor doing it with a better how?

Will a company with a strong why, a sense of purpose, that is felt and understood by all the employees help ward off the troubles of obsessing over what and how?

<comment><USER32> > But what's the stage after that?

Unfortunately I feel like I can answer this (or at least suggest a direction) from current personal experience.

When the engineers are not allowed to fix fundamental problems, the next stage is about defending themselves from blame that they feel is not rightfully theirs.

Ex: _________

"Hi Bob, this problem appears to be due to corrupt data. Our 9-year old platform does not actually use foreign-keys or database transactions, and we haven't been able to get approval to replace it."

"Alex, I haven't seen this feature before, it seems to be from the offshore contractors and their PM. Reproducing the error, it seems they introduced it about five months ago, so we'll have to check those records for mistakes."

"Mary, I'm afraid our software isn't able to support names in those languages. I'm including a link to a memo I made three years ago that explains the limitations and suggests some ways we could fix it, if the business considers it a priority."

<comment><USER13> To be fair, not being able to attribute problems to their underlying cause is a fundamental problem.

People strive for simple systems at least partly to seek property in their system.

</comment></comment></comment><comment><USER13> > Worse of all, though, his concern that "We aren't building the right thing" > will be replaced with "We aren't building the thing right."

To be fair, part of an engineer's job is to give her opinion on when you're not building the right thing _because_ you're building the right thing in the wrong way.

Building something with 10-100X more cost, unacceptable bug rates, or a pivot- unfriendly design means losing money in many (most?) contexts.

<comment><USER28> It can always be debugged in the next sprint! Just pick up another item from the board and keep coding; if we get behind we'll just hire some more college grads.

<comment><USER13> "Will this feature be profitable if it requires X more engineers per Y users?"

If the answer is yes, then I guess it's fine.

<comment><USER28> Until the code base becomes so intractable, such a dinosaur of brittle features and run-on code that nothing significant can be done without exhaustive debugging. Then no group is large enough to make good progress.

Loose wads of code with random dependencies make the effort grow geometrically. No growth in team membership can keep up with that for long. The only solution is to tightly control dependencies, write good abstractions and keep to them religiously, etc.

So many, many projects head off this particular cliff. They pretend to have life for a while, reducing the feature set in each drop to smaller and smaller items. Relabelling a bug fix a feature, and features overrun the sprint/release and get relabeled 'bugs' so you can keep developing through the test and release phases.

So many of us recognize the syndrome. But so little gets done about it, especially in large companies.

<comment><USER13> > Until the code base becomes so intractable, such a dinosaur of brittle > features and run-on code that nothing significant can be done without > exhaustive debugging.

Yes. And that gets at the point of OP. "Let me replace subsystem A so we can free up B resources per year" is a big, if it works. To throw it on the backlog for "when we get time" is self destructive in the long run.

</comment></comment></comment></comment></comment><comment><USER37> "Just want to code" as opposed to what? After reading the article, I am not sure I understand what he wants programmers to do.

<comment><USER10> I don't think the author wants programmers to "do" anything. Instead, they want managers to allow programmers to bring their whole selves to their jobs. That means not blockading their ideas from being implemented, regardless of what realm they belong in. If a programmer has a product idea, they should have a chance to prove it's a good one. If they have a process idea, it should be considered. And so on...

</comment></comment><comment><USER38> TL;DR: I lived this situation on a shitty firm. It's depressing. But "good" firms do exist, don't lose hope!

I lived this situation : I got hired as a developer and got involved into making the product better and improving our processes. But the firm was (and still is) utter shit. It was painful and I was unhappy.

Some people there are still trying to do a good job and they have had several episodes of burn-out. Some other just lowered their standard and accept to get paid to poop some ugly code and apply useless processes (some might be happy, but most of them are dead inside). I just gave up on this nonsense and quit, and was lucky enough to find a much better place. My new firm (not that "new", it's been more than a year now) is not perfect and can definitely be improved... But motivation and commitment into improving things are actually welcome, and it works!

</comment><comment><USER39> Some of these responses speak to the difference between "programming" and "software engineering". If you want people to hack code without regard for what it is for, you get programmers. If you want a team that is fully engaged in building a product (which means the whole life cycle from requirements to deployment) you need software engineers. If you disempower developers from that kind of decision making, it doesn't matter what their title is.

</comment><comment><USER40> Hah this is pretty much me at my current joint... and the worst part is it just feels like there's nothing left after.

</comment><comment><USER41> Programmers can't into graphic design - [https://youtu.be/NM1UeFFCofY](https://youtu.be/NM1UeFFCofY)

<comment><USER42> This is spam

</comment></comment><comment><USER43> It's not just programming; anything where your thoughts and concerns are automatically dismissed and shoved aside becomes incredibly demoralizing. Eventually you either give up completely, or you settle into the tiny corner where you're allowed to have opinions and act on them.</comment>


Why American Revolutionaries Admired the Rebels of Mysore (2016) - <AUTHOR> https://aeon.co/essays/why-american-revolutionaries-admired-the-rebels-of-mysore <comment><USER2> In 1799, Tipu Sultan ruler of Mysore was killed in the Fourth Anglo-Mysore war. During the war the British had faced a new military weapon, the Mysore rocket, developed by Tipu's army.

By 1804, the British had copied and refined this weapon into a long range solid fuel rocket called the Congreve rocket.

In the War of 1812 the British entered Washington DC and burned down the White House. The Royal Navy fired Congreve rockets at Fort McHenry which lit up the sky, illuminating the American flag flying over the fort.

Later Francis Scott Key memorializing the event in a poem that became the national anthem of the U.S.A : "The Star-Spangled Banner"

       ...
       And the rockets' red glare, the bombs bursting in air,
       Gave proof through the night that our flag was still
       there;
       ...

Next time you hear the U.S national anthem - remember that those rockets trace their origin to Tipu Sultan :)

[https://en.wikipedia.org/wiki/Mysorean_rockets](https://en.wikipedia.org/wiki/Mysorean_rockets)

[https://en.wikipedia.org/wiki/Congreve_rocket](https://en.wikipedia.org/wiki/Congreve_rocket)

[https://en.wikipedia.org/wiki/War_of_1812#Chesapeake_campaig...](https://en.wikipedia.org/wiki/War_of_1812#Chesapeake_campaign_and_%22The_Star- Spangled_Banner%22)

[https://en.wikipedia.org/wiki/The_Star- Spangled_Banner#Lyric...](https://en.wikipedia.org/wiki/The_Star- Spangled_Banner#Lyrics)

<comment><USER3> Love learning little facts like this!

HN has such high quality in the comments.

</comment></comment><comment><USER4> Clickbait. There is no connection between hyder ali and American revolutionaries. The revolutionaries wanted to freedom and created a democracy based on constitution. Hyder Ali betrayed his own country and fighting for himself.

<comment><USER5> "There is no connection between hyder ali and American revolutionaries."

I am curious why you say this despite all the evidence they shared in the article. I focus on just one of the items, the ship, Hyder Ally. [https://historyofmysuru.blogspot.com/2017/11/when-america- ce...](https://historyofmysuru.blogspot.com/2017/11/when-america-celebrated- warrior-from.html) "a single mast ship named Hyder Ally gave the fledgling navy of United States of America one of its greatest victories". Seems like there was enough a connection if people were naming warships after the guy.

<comment><USER6> Let me explain where parent poster is coming from. Hyder and Tipu were muslim rulers. Thanks to the patronage of the religious right leaning government, there is a concerted effort going on to remove traces of islam in india's history. Diminishing Tipu and Hyder Ali's role is just a part of the package</comment></comment></comment>


Show HN: Using Google Sheets to create a survey chat bot without a server - <AUTHOR> https://github.com/Viber/build-a-bot-with-zero-coding <comment><USER3> This is beautiful.

Also - side-note but often overlooked on open-source & github projects - <USER2> documentation / getting started guide on home page is EXCELLENT!

<comment><AUTHOR> Thanks. <3 GitHub!

</comment></comment><comment><USER4> This is great! I wonder can it be done for Telegram as well?

<comment><USER5> When I'm free this evening, I'll follow the guide and build a telegram bot. I will fork his repo if it works

<comment><USER4> Thanks. Waiting to hear more from you.

</comment></comment></comment><comment> DanI-S If you're interested in this approach, there's a similar spreadsheet-based pattern available for building trivia-style games for the Google Assistant platform:

[https://triviatemplate.com/](https://triviatemplate.com/)

</comment><comment><USER6> Seeing these chatbots I'm always wondering... Are customers rally using these? I'm wondering because it would never occur to me to chat to a chatbot.

<comment><USER5> In Russia, lots of people use telegram and the bots too. I use bots to do lots of things, from ordering pizza to managing my schedule. However, these bots are usually not NLP-powered...so there's less disaster as compared to how facebook bots rely heavily on natural language input from the user

<comment><USER7> Yeah, these are more chat wizards than chatbots... I think we should distinguish that.

<comment><USER8> So terminal UIs are coming back?

</comment></comment></comment></comment><comment><USER9> How difficult, if at all possible, would it be to add images to each question?

<comment><AUTHOR> Hi. Should be easy! I have another demo that actually send images, rich messages and other elements. However, I can't share its source code yet. Sorry!

</comment></comment><comment><USER10> I did something similar with AWS's S3, Lamba and a google spreadsheet.

</comment><comment><USER11> You have a hacienda server, you're just not managing it.

<comment><USER11> Wow, I have no idea where that came from. Hacienda should be backend.

</comment></comment><comment><USER12> They didn't approve my developer account, so, I have no incentive to look into this when Facebook Messenger, Telegram, and many others are widely available.

<comment><AUTHOR> Hi Nikolay. Viber's DevRel here. Super sorry to hear that. Can you please shot me an email over devsupport[at]viber[dot]com? I'll try to fix this.

<comment><USER12> Why do you need to manually approve at all? I have a bunch of public accounts and I want to take full advantage of those.

<comment><AUTHOR> We are working on a new better system. Should be out anytime now.

<comment><USER12> A week late - no change!

</comment></comment></comment></comment></comment><comment><USER13> That is not without a server... it's not your server, but it does have a server side.

<comment><USER14> In fairness, "serverless" architecture involves servers.

I am appalled by the constant erosion of meaning in the tech field, but there you are.

<comment><USER15> How do we refer to the type of architecture without server-side component proper[0][1][2] though? Makes it surprisingly hard to find material and research on those topics.

Recently I was looking for one insightful talk (with a PoC) where websites run completely on users' machines. It's been a couple of years since I saw that talk for the first time, "cloud" was the term of choice to refer to what's "serverless" now. I had to give up after pages upon pages of search results talking about Lambda or Azure (otherwise I'd have linked the talk here, of course).

[0] [https://github.com/jhiesey/peercloud](https://github.com/jhiesey/peercloud) [1] [https://github.com/lucaspiller/shortly](https://github.com/lucaspiller/shortly) [2] [https://paul.kinlan.me/serverless-sync-in-web- apps/](https://paul.kinlan.me/serverless-sync-in-web-apps/)

</comment></comment></comment><comment> le-mark It's curious to see these occasional "cool little apps using google sheets for a datastore" when there are _many_ "database as a service" around with free tiers, like firebase, restdb, and a whole bunch of others. Why not just use a real database instead of hacking google sheets?

<comment><USER16> Because it's cool that you can

<comment><AUTHOR> Totally agree. Personally, I just adored everything about GSuite interface. They did an amazing work.</comment></comment></comment>


The Professional Side Effects of Social Media - <AUTHOR> https://www.dmagazine.com/commercial-real-estate/2020/02/the-professional-side-effects-of-social-media/ <comment><USER2> While raising a daughter and also mentoring younger devs I've noticed their communication patterns online tend toward short and less polished.

Short to me means 1-2 sentences, even on platforms such as Slack, which is not limited to 140 characters (we have a family slack and slack bots). The sentences also tend towards brevity.

By unpolished I don't mean raw stream of thought, though I see that too. What I mean is that they may get one pass at polishing, but not the polish that's usually in a well crafted email.

These trends are most noticeable when the writing is a report, or a proposal.

When I'm doing an editing/review pass I like to check two basic things, 8WH [1][2][3] (variations have less questions, such as 5WH and 6WH) and the Heilmeier Catechism [4]. Both improve the quality a lot by themselves if present.

8WH is a mnemonic for a set of basic framing questions: Who? What? Where? Why? When? Whose? Which? For Whom? How? These questions are too ambiguous without contextualizing. For example if I was recommending a big equipment purchase:

* Who should the purchaser be?

* What needs to be purchased?

* Where will this equipment be used?

* Why does it need to be purchased? Why this make/model?

* When is it needed, and when does it need to be purchased by?

* Whose money will be used to pay for it?

* Which make and model is recommended?

* For Whom will the equipment be used?

* How will the purchase be confirmed, and tracked?

There's overlap, and sometimes some questions can be combined or eliminated, but when writing myself I try to do all of them first before consolidating.

The Heilmeier Catechism also has some overlap with 8WH, but is a useful set of questions on its own. The questions are geared to a pitch of some kind:

* What are you trying to do? Articulate your objectives using absolutely no jargon.

* How is it done today, and what are the limits of current practice?

* What is new in your approach and why do you think it will be successful?

* Who cares? If you are successful, what difference will it make?

* What are the risks?

* How much will it cost?

* How long will it take?

* What are the mid-term and final "exams" to check for success?

[1] [https://oneminuteenglish.org/en/wh- questions/](https://oneminuteenglish.org/en/wh-questions/)

[2] [https://premium.wpmudev.org/blog/a-simple-sure-fire-way- to-c...](https://premium.wpmudev.org/blog/a-simple-sure-fire-way-to-create- great-content-the-5-w-the-h/)

[3] [https://en.wikipedia.org/wiki/Five_Ws](https://en.wikipedia.org/wiki/Five_Ws)

[4] [https://www.darpa.mil/work-with-us/heilmeier- catechism](https://www.darpa.mil/work-with-us/heilmeier-catechism)</comment>


Ask HN: How do you increase your laptop battery life - <AUTHOR>

I have recently bought a new laptop, but it has a very low battery life when unplugged: about 2hours.
I have tried to increase it by closing some background applications, removing Windows Aero, but I have to do it manually every time I unplug the laptop.
Closing the background processes one by one takes time, is there no application for doing it in once click (by preselecting which processes I want to stop)? <comment><USER2> Right click on the battery icon and go to Power Options. Under "Select a Power Plan" you'll see which plan you have selected (e.g. Recommended, Power Saver, High Performance). Click "Change Plan Settings" and then "Change Advanced Power Settings" under the battery column to get to a menu that lets you change everything that affects power. Turn WiFi to power saving mode if you have a strong signal. Turn USB to selective suspend if you don't have anything plugged in. PCI Express to maximum power savings. I leave the processor at 100%, but you can change this to 75% or lower if you're just browsing. Just keep an eye on the number of programs running. Search and Indexing shoule be set to power saving (windows can organize your MP3 collection for faster searches later). I set my display to the minimum when on battery, and turn it up manually if it's too dim.

Once you have all of these settings tweaked, the computer will automatically use them whenever it's on batteries alone, and revert when you're plugged in.

<comment><AUTHOR> Thanks, I did it.

But I do have software (e.g. Memeo AutoSync, UltraMon, Phone Remote Control, Airytech Switch Odd) that I wish to shutdown automatically when on battery power, as I don't necessarily need it then, and they use some CPU power.

However closing each separately takes some time and work (+later I have to restart them when I plug in), is there no software that can manage that? No software developer got this idea?</comment></comment>


GauGAN Turns Doodles into Stunning, Photorealistic Landscapes - <AUTHOR> https://blogs.nvidia.com/blog/2019/03/18/gaugan-photorealistic-landscapes-nvidia-research/ <comment><USER2> This is a very interesting use of the technology, which I hadn't thought of before.

I would really like to see the tool open-sourced. I guess that re-training the networks on a custom dataset could quickly lead to some interesting results. Even in its current incarnation, the tool could be quite entertaining.

It might also be interesting to apply the methods here to 3D environments, which are typically designed with placeholder objects and textures. I wouldn't be surprised if this were to be applied in videogames to save both on development time (art costs), and file size (multi-gigabyte texture files seems to be quite common), as a complement to procedural generation.

Given nVidia's recent publications [1] on this topic, it seems like they are not too far away from offering that kind of facilities to partner game developers.

Also of interest related to this software: [https://nvlabs.github.io/SPADE/](https://nvlabs.github.io/SPADE/) [https://github.com/NVlabs/SPADE](https://github.com/NVlabs/SPADE)

[1]: I'm mainly thinking of [https://www.lyrn.ai/2018/12/26/a-style-based- generator-archi...](https://www.lyrn.ai/2018/12/26/a-style-based-generator- architecture-for-generative-adversarial-networks/)</comment>


Onesignal: Product and Policy Updates for GDPR - <AUTHOR> https://onesignal.com/blog/product-policy-updates-for-gdpr/ <comment><AUTHOR> _Specific product changes include:

Providing the option to not store end-user IP addresses, and by default, not storing the IP addresses of end-users from countries within the EU.

For all clients, beginning on May 21st, 2018, we will discontinue building data models with data nor will we monetize any EU user data with our business and analytics partners. For our Enterprise clients, we have introduced a Data Processor Agreement (DPA) which formally designates us as a Processor for all data.

Releasing updated versions of our SDKs to make it easier for our clients to prevent user data from being sent to OneSignal until a user explicitly consents,

Adding support to our API for the deletion of user data. Additionally, we are reducing our data retention period of deleted data to 72 hours.

Updating our user data exporting capabilities to make it easier to search for and export user data from OneSignal. This will help our clients meet individual user requests for restriction, erasure, and data portability.

Preparing a guide on how to use OneSignal for push notifications without sending us personal user data._</comment>


AT&T/Verizon lobbyists to "aggressively" sue states that enact net neutrality - <AUTHOR> https://arstechnica.com/tech-policy/2018/03/attverizon-lobbyists-to-aggressively-sue-states-that-enact-net-neutrality/ <comment><USER2> > "All Americans Deserve Equal Rights Online."

Didn't they already have that with the net neutrality rules they've just fought to kill?</comment>


Using Swift with Cocoa and Objective-C - <AUTHOR> https://itunes.apple.com/book/using-swift-cocoa-objective/id888894773

<comment><USER2> Well this is rather upsetting, it seems extensions still cannot add stored properties... Back to using objc_setassociatedobject and objc_getassociatedobject it seems for extension properties, sadface.

Also seems you can't override existing methods or properties still (actually achievable with swizzling of methods & property getter/setters on init but always seems way to heavy to use in reality). I would love to have a more mix- in friendly environment at some point in time.

"You can use extensions to add properties (including class and static properties). However, these properties must be computed; extensions can't add stored properties to classes, structures, or enumerations."

"You cannot use extensions to override existing methods or properties on Objective-C types."

Excerpt From: Apple Inc. "Using Swift with Cocoa and Objective-C." iBooks.

<comment><USER3> Not surprising. Class extensions in Objective-C cannot add stored properties either; objc_setassociatedobject and objc_getassociatedobject are shitty hacks.

</comment></comment><comment><USER4> PDF: [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/swift/conceptual/buildingcocoaapps/BuildingCocoaApps.pdf)

</comment><comment><USER5> This is the same as the online documentation that's been up since release: [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/)

<comment><USER6> Thanks. Burying as dupe.

</comment></comment><comment><USER7> Awesome. I just finished a small Mac App in Swift [1], and I've run into lots of small situations where I wasn't sure what the best practice would be. Really looking forward to reading this one.

In particular, I found the required casting of AnyObject! to whatever I was expecting it to be not perfect (sometimes I thought that the typechecker really ought to figure some types out). Also, best practices for when to use NSArray vs. Array / NSString vs. String, etc. is another thing I look forward to.

Also, Some of the issues I ran into are probably due to Swift being beta, so knowing what the right way _should_ be (even though it doesn't work that way yet) is important as it keeps me from hanging on to bad style.

[1] [https://github.com/terhechte/Swijito](https://github.com/terhechte/Swijito)

<comment> k-mcgrady >> "In particular, I found the required casting of AnyObject! to whatever I was expecting it to be not perfect (sometimes I thought that the typechecker really ought to figure some types out). Also, best practices for when to use NSArray vs. Array / NSString vs. String, etc. is another thing I look forward to."

Same issues I was having. I was porting an obj-c class to Swift and continued to use obj-c objects (NSString etc.). I then had to put 'as NSString' at the end of most lines. I'm considering going back and experimenting to see where I can use swift native objects. Hopefully this book will shed more light on the subject.

</comment></comment><comment><USER8> _For consistency and simplicity, Objective-C factory methods get mapped as convenience initializers in Swift. This mapping allows them to be used with the same concise, clear syntax as initializers. For example, whereas in Objective-C you would call this factory method like this:_

        UIColor *color = [UIColor colorWithRed:0.5 green:0.0 blue:0.5 alpha:1.0];

_In Swift, you call it like this:_

        let color = UIColor(red: 0.5, green: 0.0, blue: 0.5, alpha: 1.0)

I'm still unclear on how this is happening behind the scenes?

<comment><USER9> They generate new Swift headers for Objective-C classes, and have translation rules in their toolset to remap/rename some arguments (all the init methods for example). The tool can even do that on your own Objective-C projects. I used this on a side project this weekend and it's pretty rad.

<comment><USER8> Are these translation rules published somewhere? I'd really like to understand what keywords trigger what kind of mapping rules.

<comment><USER10> I'm pretty sure that's just a misstatement in the documentation. The Swift code is equivalent to the UIColor initialiser, there's no need to auto- translate the factory method as well.

The auto-translation process for initialisers is described immediately before the part you quote.

<comment><USER8> The section above mentions specifically translating either "init" or "initWith" from initializers. I'm curious if they're also pattern matching the "colorWith" prefix or if its more complicated.

<comment><USER10> I think you might have missed my point: the `initWith` translation produces the Swift constructor that the documentation you quoted presents as the factory method equivalent.

The `colorWith` factory method is useless in this context because a matching `initWith` initialiser exists. If the factory method were pattern matched in the same way, it would break things because it would produce a constructor with the same method signature as the translated initialiser.

<comment><USER11> We actually _do_ pattern match UI _Color_ _colorWith_ and turn it into an initializer. If there are two initializers after we pattern match (e.g., UIColor colorWith and initWith), we eliminate the duplicate.

<comment><USER8> Are there other pattern matches that can get triggered? I've come across classes that initialize with "For" as in [MyClass classForString:str] or similar.

<comment><USER12> From what I've been able to figure out just by playing around, the following rules are used:

1\. Return type is `instancetype` or `MyClassName *`

2\. Method takes at least one argument

3\. Method name starts with a "class suffix"; that is, a suffix of the class name, with the restriction that you can't have partial words. The first letter may optionally be lower case.

The class suffix (optionally followed by "With" like in the `initWith` conversion) is stripped off and the rest of the method name is used for the first parameter, with the first letter lower-cased.

For example, the following conversions apply:

      +[MyClassName myClassNameWithObject:obj] -> MyClassName(object: obj)
      +[MyClassName classNameWithObject:obj] -> MyClassName(object: obj)
      +[MyClassName nameObject:obj] -> MyClassName(object: obj);

However, since those all map to the same swift initializer, only one will be available (generally the first one declared)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> English book here (Canada link but should redirect you): [https://itunes.apple.com/ca/book/using-swift-cocoa- objective...](https://itunes.apple.com/ca/book/using-swift-cocoa- objective/id888894773?mt=11)

</comment><comment> k-mcgrady I'm getting 'this page is temporarily unavailable' on this new book and the first one in the iBooks app on Mac. Edit: UK store so maybe it's still propagating to all stores.

</comment><comment><USER14> I wish there was a properly formatted pdf version of the language guide. There is one floating around but the font size is too small.

</comment><comment><USER15> What language is this in?

<comment><USER16> I think, Italian? if you switch the language specified in the url from 'it' to 'en' you get English, and I imagine 'it' stands for Italian.

<comment><AUTHOR> English

</comment></comment></comment><comment><USER17> This page is in Italian.

<comment><USER18> It's from the Italian store. The book is in English though.

Here's a full English link: [https://itunes.apple.com/us/book/using-swift- cocoa-objective...](https://itunes.apple.com/us/book/using-swift-cocoa- objective/id888894773?mt=11)

<comment><USER17> Thanks, pretty cool I just noticed if you change the /us/ part to any other country like cn, es, gb or it you will get the page in that language.

<comment> k-mcgrady If you just click on the big blue button it will open in the correct store for you location.

<comment><USER17> How would that help? The computer I am using doesnt have ibooks or itunes.

<comment> k-mcgrady It sounded like you...wanted to read the book which would require iBooks. I'm guessing you were just interested in an English translation of the summary?

<comment><USER17> Exactly.</comment></comment></comment></comment></comment></comment></comment>


Scaling out Postgres, Part 1: Partitioning - <AUTHOR> http://petrohi.me/post/30848036722/scaling-out-postgres-partitioning <comment><USER2> Craig, thanks for sharing Peter's article. As a side note, we started on Heroku (on the cedar stack as well as actually working out of the Heroku office -- we're big fans). We're now hosting with Liquid Web on dedicated db boxes due to the large RAM and IO speed requirements of our app.

We also initially wrote the app to use a mix of Postgres and MongoDB but ended up moving everything into Postgres.

<comment><USER3> What were the reasons for moving away from MongoDB?

<comment><USER2> Our app does a lot of writing. We were on Mongo 1.8 which has a global write lock. So concurrency was a big problem under load. We also have a lot of users with networks of 200k+ people – not even including followers. This meant that we had to have arrays in the User collection with 200k+ IDs to perform a lot of our queries. The RAM needed for indexes wasn't really worth the cost and performance started to become a big concern. In the end, our data makes more sense in SQL with a cache layer (Redis in our case) rather than NoSQL.

Our experience thus far in Mongo vs Postgres: go with what you know. We probably could have made Mongo work for us (especially Mongo 2.0+), but it was easier for us to work out the performance issues with Postgres. Plus, things made more sense in SQL.

If you're using Mongo and need a cloud provider, I can recommend the people at MongoLab. They really went above and beyond helping us get up and running and are really cool people.

<comment><USER3> Thanks for the summary.

</comment></comment></comment></comment><comment><USER4> Maybe I'm not understanding something, but there seems to be an implicit assumption that the message broker (RabbitMQ) is more reliable than the database. This seems to be a common fallacy.

<comment><USER5> Yes, I can see where you're coming from. Message queue in the article is more of an abstract service that provides certain guarantees and less of a specific RabbitMQ implementation. There are examples of message queues implementations on top of database--the resulting tradeoffs can be an interesting discussion.

</comment></comment><comment><USER6> Glad to see you are having "good problems".

Didn't like parallel queries using pgpool2?

<comment><USER5> We are planning to use pgpool2, but only for connection pooling. In our case the subset of postgres databases to execute a distributed query is dependent on the input parameters, current sharding configuration and cached routes. Cached routes are used to handle adding new shards without repartitioning--I will cover this in the second part.

I guess we could use pgpool2 parallel queries, but this would likely require some adjustments in how they are implemented.

</comment></comment><comment><USER7> Having to implement your own sharding in your application layer for a database with 3 tables is ridiculous.

No wonder people are moving to products like Cassandra, HBase, MongoDB, CouchDB etc which automatically and transparently shard across as many nodes as you like.

<comment><USER8> I don't have any experience with HBase and CouchDB, but Cassandra and MongoDB will only shard automatically and transparently if your application does not do much writing. :-P

Also, the number of tables has nothing to with the problem of sharding, it's the amount of data you're trying to store.

<comment><USER7> I suppose you would have an issue with MongoDB specifically if you were trying to rebalance from day one. But generally you wouldn't. I know Foursquare is using MongoDB's Auto Sharding in production and they would definitely have a lot of writes.

And the number of tables DOES matter for sharding if you are implementing it yourself.

<comment><USER8> Foursquare's experience with sharding MongoDB has, as far as I understand, been far from automatic and transparent (based on their blog posts and the word on the street).

<comment><USER7> I've heard Foursquare having a lot of problems with the terrible behaviour of MongoDB once your indexes go above 95% of the machine's memory.

Never with the sharding part though.</comment></comment></comment></comment></comment>