Why Thailand's Women Are So Successful in Business - <AUTHOR> https://www.bloomberg.com/news/articles/2019-02-25/women-gain-ground-in-thai-c-suites-not-so-much-in-government <comment><AUTHOR> Excuse the original title being politics-related, the actual content is not much so.

Seeing topics about gender equality and workplace diversity pop up on HN from time to time, I'm hoping this might spark some good conversation around women leadership and not on the politics side of things.</comment>


Ask YC: Top tips between coding and launch - <AUTHOR>

I've been trying to make a list of things I always forget to do when I'm preparing to launch my web project.
Stuff like register your brand on twitter, ask mechanical turkers to test the final UI, ensure you have web stats enabled, all your google alerts working, etc.
What do you do just before launching your new project? <comment><USER2> _What do you do just before launching your new project?_

More coding.

I don't understand this idea of "time between coding and launch".

<comment><AUTHOR> I expected "more testing" too :)

<comment><USER2> Well, you asked what I did. I do more coding; my users do more testing. :-)

</comment></comment></comment><comment><AUTHOR> something I always do with stuff with RSS feeds - make sure they're passed via feedburner.

<comment><USER3> "make sure they're passed via feedburner."

Isn't it now make sure they're NOT passed via feedburner?</comment></comment>


A simple pomodoro made in C - <AUTHOR> https://github.com/nikumu/pomodoro-timer <comment><USER2> This accout submitted this 3 times in less than a day.

<comment><USER3> probably has something to do with the sketchy code sponsor thing in the readme file

<comment><USER4> This is Eric, the founder of Code Sponsor. I assure you there's nothing sketchy with what we do. There is, however, something sketchy about this developers abuse of it. We have removed ourselves from their repository.</comment></comment></comment>


Never Have the "What Would It Take to Keep You Here?" Conversation - <AUTHOR> http://moz.com/rand/never-have-the-what-would-it-take-to-keep-you-here-conversation/ <comment><USER2> I think it's first worth having policies that recognize the modern knowledge worker. Unlimited vacation, hardware budgets, a results-only work environment, optional meetings. No company bullshit. Etc. That way folks won't go "maybe a vacation will help" - because you've already done it.

Of course, that is just removing roadblocks. That's not an active measure. You should be having weekly one on ones with all direct reports (and so on up and down the chain). Rarely when a coworker quits is it completely unexpected. At some point a switch is flipped from "not going to even consider it" to "sure, I'll talk to recruiters." And then the clock starts ticking. In some ways, the organization has already lost if it got to that point.

Raises and titles are not the only thing that drives people; I'd probably argue that's the worst sort of extrinsic motivation. If a bigger title is all that keeps someone working there, you've already failed. As a manager it's your job to know what motivates your people and help get them there accordingly.

<comment><USER3> > Unlimited vacation, hardware budgets, a results-only work environment, > optional meetings. No company bullshit.

Aside: I've become convinced unlimited vacation policies are a bad idea at scale. Everywhere I've seen them applied, they lead to less vacationing for the people who need it most: the eternally stressed and overworked who feel like the world will end in their absence or that they will get dinged or plain fired in their next performance review if they're not always in the office. You don't need to force people to take a vacation, but the old system of assigning them a fixed number of yearly days with some sort of limited rollover strikes a good balance I see no reason to upset. A system based on firm expectations can still accommodate exceptional events like honeymoons.

<comment><USER4> Unlimited vacation policies are a bad idea even on the small scale. Even on our team of 5, some of us sucked at taking time off. Those of us who didn't suck at taking time off sucked at not feeling guilty about it!

I'm still thinking about the side effects of a "Paid Paid Vacation" policy. That is, instead of getting N weeks of paid time off, you get $X per week of vacation used, up to some limit.

<comment><USER5> That's actually a pretty good idea.

</comment></comment></comment></comment><comment><USER6> When someone says it's about the money, it's never about the money.

So in order to prevent the "I have a better offer" discussion, you have to innoculate your people ahead of time. Make them immune to better offers by making them unavailable to those who would make them.

Find out what really motivates each person and engineer the "perfect job description" for them:

      - meaningful work
      - quality working conditions
      - proper work/life balance
      - appropriate compensation / benefits
      - a well-defined mutually agreed upon future career path
      - proper recognition
      - congruent culture (work mates)

Make it so that people _love_ coming to work. It's not that hard if you really want to.

Do that and you will never lose them. If you can't (or won't), then they were never really yours in the first place.

<comment><USER7> > \- meaningful work

One thing that you didn't mention and that has been very important in the decision making process of my recent job search would be:

      - hard work

The vast majority of the jobs out there are run-of-the-mill scale this CRUD thing jobs. Nothing wrong with that but if a company can offer me the opportunity and trust to work on something that is technically very hard, then that is a definitive bonus (although it's not possible for all types of companies to offer that kind of work to engineers)

<comment><USER8> What do you mean by hard? Hard like design an exciting new nonosql datastore? Or hard like refactoring and fixing an enormous crud codebase with myriad of hidden dependencies?

<comment><USER7> As I said above: Hard like technically hard: AI, Machine learning, generally designing new algorithms, language design, crypto, distributed systems, computer vision, compilers, and so on and so forth

>exciting new nonosql

also nice try at drawing a false dichotomy between CRUD stuff and "reckless" NoSQL DBs.

<comment><USER8> the legacy codebase refactoring is likely harder than designing new algorithm and all.

</comment></comment></comment></comment></comment><comment><USER9> In my experience, companies that find themselves in the "What Would It Take to Keep You Here?" situation are rarely ever prepared to actually do what it would take to keep you there. The very next sentence out of their mouths is usually "but only management is eligible for that level of..."

<comment><USER10> "OK, but to be honest we just don't have that money available at the moment. Is there anything _else_ we could do? We don't want to lose you, but we have to be realistic."

</comment></comment><comment><USER11> _As a CEO, many of the scariest days I've faced have been those when a critical member of our team told us they were leaving the company. Your heart sinks..._

I'm always happy to hear that a company values their employees, and takes a proactive approach to keep them happy. I'm also surprised how little some companies do on that same front, and only scramble to analyze pay, work conditions, etc. _after_ an employee has announced they're leaving. By then it's too late.

One case that sticks out for me was a few years back when a brilliant lead dev I know left the company he was working for. I knew the company's work conditions weren't favorable, he didn't have a job title worthy of what he was doing day to day, and after hearing the salary he was being paid (about half a typical market-rate salary at the time), my only question was why he hadn't left earlier.

So I think a lot of companies encourage their employees to leave without even knowing it. Or even worse, they know they're shortchanging them on some level and gamble on fear or ignorance in hopes that said employees feel they're getting a fair deal. I believe this to be the case with the example I cited above, and am glad the lead dev has since found a company with much better work conditions across the board.

<comment><USER12> I was in a pretty similar situation recently. After more firewood was thrown on the fire, I decided to start looking, and at that point I had already decided not to accept any counter-offer. Not only was I being shortchanged on salary (significantly), but also in benefits, perks, and working conditions. I'm really happy I found an awesome startup in SF that still after a month feels like an ideal workplace for me.

When I was looking, I was disconcerted when I found companies with no personal growth prospects or that flat out said they wouldn't pay what I was asking (fair) because they didn't want to pay two engineers with the same title too differently. I asked if they would offer bonuses to compensate or if they'd consider paying the other guy the same salary, because he seemed smart enough. No to both, and I felt that alone indicated that management there didn't value engineering talent.

I really hope this treatment of talented workers isn't too pervasive in the industry. Pay people what they're worth. Strive to offer the best working conditions, benefits, and perks. Take the values of your employees into consideration. It really doesn't seem like it's too much to ask for. And personally, I'm all for complete transparency within my company, even to the point of salary information. I think it would resolve more issues than it would cause.

<comment><USER11> _I asked if they would offer bonuses to compensate or if they'd consider paying the other guy the same salary, because he seemed smart enough. No to both, and I felt that alone indicated that management there didn't value engineering talent._

That's awesome that you vouched for the other guy. And I wonder what technical experience management or upper-level execs had at that company. I find that when there's very little to none at those levels in the company, they'll tend to be similar to what you described. Ultimately they view engineers as a commodity resource and try to get by with the "cheapest" deal they can.

I've found many of the same companies also suffer from high turnover, and turn a blind eye to the long term drag that imposes on their software. For companies that profit in the tens or hundreds of millions of dollars a year (e.g. the company I mentioned previously), I think it's silly they resort to offering market, or below market, wages to save a few bucks (relatively speaking) vs. striving to have happier employees, and retaining them for a longer period of time.

</comment></comment></comment><comment><USER13> It seems that in this post a title change was given without a raise. I don't necessarily think that doing that is such a good idea. I know the post says that they were already being compensated fairly. Here's why I think promotions without pay are a bad idea: It gives the employee more incentive to leave, and very little to stay. Superiors tend to give titles pretty easily because it's "free", but I think it may actually cost the company more in the long run. It's a gambler's play.

<comment><USER14> That's an incorrect assumption. We gave raises to both Adam & Jamie commensurate with their new titles/roles.

<comment><USER13> Rand, in the email included in the post you wrote, "They're compensated fairly, IMO, but both deserve the titles they've been aiming for."

That's what led me to that conclusion.

</comment></comment></comment><comment><USER15> I think there's much more evidence that there is a management mandate to squeeze as much as possible out of salaried employees than there is about counter-offered employees having their head on a block under management efforts to replace the perceived-disloyal. The proactivity being championed in the post and comments does not have industry support and any manager who suggests giving raises or benefits ahead of time likely has the Sword of Damocles hanging over _them_ afterwards.

<comment><USER16> I don't think this post, or most best-practice type articles, is trying to describe how things generally work, or even trying to push it as mainstream knowledge. Instead it's someone who has gained enlightenment trying to get through to people with open minds.

On this general topic, not only should you ensure that you don't lose your best people externally, more importantly you shouldn't lose your best people internally -- that they turn into not-your-best-people because they know they're underappreciated but don't have the willpower to leave, but instead try to passively setup a situation where they're asked to go.

<comment><USER15> Sure, "shouldn't," but in my experience the second case is far, far more prevalent, using Machiavelli and Sun Tzu as management techniques, keeping good people on board as well as a lower burn rate than they would if their board allowed them to proactively secure their staff..

</comment></comment></comment><comment><USER17> That's one thing I've learned from Hacker News, that the ability to identify the right people to hire and promote is the lifeblood of an organisation. It seems like such a crime that big companies would delegate these to central departments who barely know how the teams are going or even what they do

<comment><USER18> > It seems like such a crime that big companies would delegate these to > central departments who barely know how the teams are going or even what > they do

It is, but its also an opportunity for smaller business to more effectively compete

</comment></comment><comment><USER19> I don't think you should expect employers to make pre-emptive strikes. This is a geek rationalisation for passive behaviour. As a talented employee, you should speak to your employer and tell them that you believe you're worth more to them than they're currently valuing you (do not threaten them with leaving though). If they don't understand the significance of you stating this to them, then leave and it will become apparent to them. (But it is better to give them the information before doing so.)

For profitability, it's more important to keep the cost of employees down, than it is to helpfully negotiate value-creators into better positions. (If you were to do so, then how do you defend it to your investors? You can't prove they were about to leave...)

If you are worried about single points of failure leaving, then request that another employee be hired and mentored into understanding of the SPOF. Even better create intrinsic motivations so you can have more confidence this won't happen. Ask employees if they're doing work they love, create a fun company culture, etc.

I kind of see this whole article as feel-good for the non-ownership class.

<comment><USER20> _I don't think you should expect employers to make pre-emptive strikes. This is a geek rationalisation for passive behaviour. As a talented employee, you should speak to your employer and tell them that you believe you're worth more to them than they're currently valuing you (do not threaten them with leaving though). If they don't understand the significance of you stating this to them, then leave and it will become apparent to them._

One thing that many engineers fail to recognize is that their managers are often more overworked than they are. They take being "ignored" personally, when reality is that their managers have a million plates spinning at once.

This is why it's considered distasteful to ask for a transfer or better project at 6 months. To the employee, that's a long time. To the manager, that person just came on board. If the manager has 12 reports, then the effective tenure (absolute tenure, divided by number of reports) is 0.5 months.

Which supports my long-standing contention that open allocation is superior. Expecting managers to control the division of labor in addition to the other work they have is just too much.

</comment></comment><comment><USER21> I like the idea of regularly evaluating what you would do to keep someone, and then just doing it. Perhaps make it a six monthly thing.

I think I came across this idea in a Netflix culture slide deck first and it stuck with me.

<comment><USER22> This seems like it could be double sided. What happens when you realize someone hasn't held up to their last evaluation?

<comment><USER23> Then you start a conversation about what's going on. The point here isn't about offering extra compensation to keep people. It's about keeping an open dialog so they know you appreciate their work (and conversely if there's a problem, you talk about it early instead of letting it fester).

</comment></comment></comment><comment><USER24> The email featured in the article bothers me. First line: "If either were to come to us with a competing offer, we'd work with all our might to keep them". Then, almost in the same breath "They're fairly compensated, IMO." Cognitive dissonance, anyone?

<comment><USER14> It was my belief that at the time, they were fairly compensated for the roles they held at the VP level. When we moved them up to officer titles and roles, we did increase compensation as well. Our standard policy is that we always pay above the 50th percentile and below the 90th percentile based on available salary data. We've got a really nice set from a wide survey of VC investors based on portfolio company size, stage, etc. and combine that with info from Salary.com and Payscale, too.

<comment><USER25> > Our standard policy is that we always pay above the 50th percentile and > below the 90th percentile based on available salary data.

That's such a confusing standard. It means that a majority of your employees could get a nice raise by changing companies, no?

<comment><USER26> Glad I'm not the only one that was thinking that.

Is that a public policy?

</comment></comment></comment></comment><comment><USER27> As an early employee of a startup, what keeps me here are my stock options. REAL ownership of a company.

I didn't join the company to get a vacation or a title bump. I joined because I believe in the vision, the people and the hope that some day my stock will be worth something.

If you can create a meritocracy where employees understand that the company's success translates to their own personal success, then they're much less likely to leave.

<comment><USER28> If you aren't one of the founders, you aren't going to make anything. Sorry. We've all been there.

<comment><USER27> Just like how Adam D'angelo didn't make anything from Facebook?

<comment><USER28> I wish you the best of luck. And I hope your employer is the next Facebook, I really do.

I'm just saying, many of us have been in that position and learned a valuable lesson. Don't be surprised.

</comment></comment></comment></comment><comment><USER29> As always, it comes down to "if you want your employee to stay, give him a raise (salary, title, perks, ...) according to his skill BEFORE he tries to leave with a competing offer".

There was a post on hacker news a few days ago where everyone was saying that in their experience, non-minimal pay raises always came with changing job, not with normal raises within their current position. Same for me, pay raises always meant changing job, with my employer realizing "oh wait, we were paying you as X but you're actually worth Y, now that you noticed let us offer you an appropriate salary". No thanks.

That's why when google started giving huge pay raises to a lot of people a couple years ago to keep them I actually thought it was a good idea, and more people should do that; if your employees are good, giving them a raise is usually a lot cheaper and easier than finding someone of the same skill and experience.

<comment><USER30> It really seems like that is the only way to make significant progress (as far as salary) in your career. You either jump ship or get a competing offer so your current company can match. If I came in with a competing offer that paid me 15-20% more and the company can match, then why didn't they just give me a raise in the first place? It probably would have stopped me from even being interested in other positions.

</comment></comment><comment><USER31> Companies need to focus more on _"What we should be doing to ensure our best employees are happy and not looking to move"_ rather than the _"Oh you are leaving. What can we do for you ? btw, we cannot do this this and this. other than all this, sure we can do blah"_

</comment><comment><USER5> That mock monologue is actually really spot on. I just recently left our bootstrapped startup and had a pre-emotive conversation shortly before doing so. It played out just like that.

I shared this link on HN already but since its so relavent here it is again. I wrote about why I still left. But didn't write about the conversation I had. And you hit it on the head. <http://mustefa.com/looking-back-at-my-ux-career- in-2012/>

</comment><comment><USER32> I'm legitimately curious for my own early-stage CEO sake: why did you have to ask the board just to promote them?

EDIT: nvm, on re-read, I see you were just asking for feedback. I wasn't sure if you needed permission from your board to promote to CMO, etc.

<comment><USER14> I think technically, I may not have needed board permission to make the move, but certainly any time you're promoting to officer level, you should be informing your board/investors.

<comment><USER32> Thanks Rand, makes sense!

</comment></comment></comment><comment><USER33> Years ago: My boss found out I wanted to leave.

Got double the pay and free rent on my apartment.

<comment><USER34> Did you leave anyway? Are you still staying now out of loyalty even though it is likely you are worth more than what the company pays you (and probably haven't put out your feelers)?

<comment><USER33> I left a year later.

Going from leading a team to dealing with career politicians wasn't my idea of fun.

<comment><USER35> Here is the big kicker you won't read catchy blog posts about.

All the recognition, perks, and compensation in the world don't make it worth working with 'career politicians' or employees who don't pull their weight in management positions.

I don't think there is an easy fix, once a company reaches a certain size these problems become unavoidable. A hiring slip-up occurs, and it isn't fixed because of some conflict with other perks. An incompetent manager takes advantage of a results oriented work environment. A shitty hire lands on a team with a remote supervisor. Or some combination of both causes a rift that doesn't close, and good workers associated with the team have to bail. Boom, your organization has a bedsore that won't heal.

</comment></comment></comment></comment><comment><USER5> I read some of the comments about employee passiveness. Sometimes it's tough for an employee to put themselves on the spot like that. What if the conversation doesn't go the 'right' way?

</comment><comment><USER36> The answer may be more equity than you're willing to give to "just a developer". Awards and titles are cheap by comparison.

</comment><comment><USER37> A fine sentiment. And considering the pressures of an average business, probably not observed very often.

</comment><comment><USER38> What if he/she is a real gem and you know it!</comment>


Ask HN: What should I ask for in salary negotiations? - <AUTHOR>

I'll be graduating in May and I've luckily been introduced to a company who is currently in need of a technical writer to support one of their software teams. The job entails documenting the company's APIs and is a pretty good gig for someone just starting out. I have some experience with software development though I'm not an expert and I'll be having my first phone interview in a couple of days and I know that if I do well enough I'll have to discuss salary which always makes me nervous. So, what sort of figure should I give so that I don't look arrogant but, also, so that I won't undervalue myself? <comment><USER2> Don't offer a figure. Try to do research on pay for similar positions (look in various locations around the country, possibly using glassdoor and a cost of living adjustment calculator) but this should be for your own comfort.

[1] sums it up, the essence is that they know better than you what they can afford and that by offering a number you only disadvantage yourself. If you're uncomfortable about negotiating an optimal package just make them make you an offer and if it exceeds a threshold take it...

[1] <http://www.kalzumeus.com/2012/01/23/salary-negotiation/>

<comment><USER3> Yes, don't offer a number. They might make you feel silly for you not offering one but that's part of their tactic. Just mention your qualifications and that you want to be paid market rate or slightly above.

Also, apply to several other jobs so you have competing offers. Do mention your other applications if specifically asked. And in end-stage negotiations feel free to play the companies off each other, such as "Sorry, I'd really love to accept, but I have a competing offer that makes much more financial sense for me at this point. I haven't firmly accepted the other offer yet, as it's been a very difficult decision since your company has such a wonderful opportunity." But don't bluff and don't act like you're taking a bank hostage; be civil, honest, and prepared to follow through on what you say. And at this point, Joel's advice applies: <http://www.joelonsoftware.com/items/2008/11/26.html>

But at the end of the day don't get too wrapped up in money or extracting maximum value. You have years and years to climb the pay ladder.

</comment></comment><comment><USER4> I'm assuming that you are in tech, and specifically a programmer. In negotiations, it's standard procedure to start by asking for something absurd. I would ask for what you make now + 30%, or what you think they will pay +30%. Either they will counter-offer something more reasonable, or they will balk and retract the offer. If they retract the offer, you didn't want to work there.

If you _need_ a job because you are unemployed or something, well, that's a different situation entirely.

</comment><comment><USER5> Above all, find other people in your position and area and ask them what they make.

In addition to salary, also consider equity, which is a different discussion depending on the size and stage of the company.

Piaw Na's book has a good chapter on compensation negotiation regardless of your geographic area. It's well worth the $25: <http://books.piaw.net/guide/index.html>

See also iaw's advice. Good luck!</comment>


Google's plan for cable and carriers - <AUTHOR> http://pandodaily.com/2013/04/19/googles-fiber-takeover-plan-expands-will-kill-cable-and-carriers/

<comment><USER2> This article is pretty far fetched on timing. To think that Google Fiber will kill off major carriers/internet providers in 5 years is absurd. Realistically, 15+ years would sound about right. Just laying the groundwork on infrastructure alone would kill the 5 year plan. I do applaud Google for doing this, as this will eventually bring the U.S. to competitive internet speeds for the masses.</comment>


Most Influential OOPSLA Paper Award - <AUTHOR> http://www.sigplan.org/Awards/OOPSLA/

<comment><USER2> People I find underestimate how much thinking and engineering went into the Java Virtual Machine. The language isn't the most expressive, but VM knowledge and technology in general grew massively from IBM and Sun's investment, and if you look at the papers in this list. The JVM also stood on the shoulders of giants (Guy Steele & LISP , David Ungar & Self, etc.)

<comment><USER3> [http://en.wikipedia.org/wiki/P-code_machine](http://en.wikipedia.org/wiki/P-code_machine)</comment></comment>


The New Yorker on mind hacks - <AUTHOR> http://radian.org/notebook/mind-hacks <comment><USER2> Why not link to the actual articles, instead of a blog that adds little original content?

[http://www.newyorker.com/reporting/2009/04/27/090427fa_fact_...](http://www.newyorker.com/reporting/2009/04/27/090427fa_fact_talbot?currentPage=all)

[http://radian.org/notebook/wp- content/uploads/2009/04/brain-...](http://radian.org/notebook/wp- content/uploads/2009/04/brain-botox.pdf)

<comment><USER3> Personally, I think the blog-post author deserves the traffic. He through the trouble of putting up that PDF (which is excellent, btw) and will bear the cost of the bandwidth. Would you have dug it up otherwise?

<comment><USER2> He doesn't have any ads on his site, so it isn't like the traffic to the blog makes him money ...</comment></comment></comment>


United bans researcher from flight after 'joke tweet' - <AUTHOR> http://www.bbc.com/news/technology-32380071

<comment><USER2> Discussion: [https://news.ycombinator.com/item?id=9402336](https://news.ycombinator.com/item?id=9402336)

Other submissions, some with a few comments:

[https://news.ycombinator.com/item?id=9394364](https://news.ycombinator.com/item?id=9394364) : 4 comments

[https://news.ycombinator.com/item?id=9397675](https://news.ycombinator.com/item?id=9397675) : 2 comments

[https://news.ycombinator.com/item?id=9394147](https://news.ycombinator.com/item?id=9394147)

[https://news.ycombinator.com/item?id=9397814](https://news.ycombinator.com/item?id=9397814)

[https://news.ycombinator.com/item?id=9394147](https://news.ycombinator.com/item?id=9394147)

[https://news.ycombinator.com/item?id=9403338](https://news.ycombinator.com/item?id=9403338)

[https://news.ycombinator.com/item?id=9408368](https://news.ycombinator.com/item?id=9408368)

There may be more ...</comment>


Coverage of a Disinformation Operation Against 2019 EU Parliamentary Elections - <AUTHOR> https://labsblog.f-secure.com/2019/05/24/live-coverage-of-a-disinformation-operation-against-the-2019-eu-parliamentary-elections/ <comment><USER2> To answer the question at the end of the post: probably none.

As others have said, it's incredibly unlikely that a tweet is going to change your mind about anything.

Having worked both in and out of the journalism industry, I know that journalists get a lot more worked up about what people say online than everyone else does. They think it matters a lot more than it does (probably why they got into the job of saying things online in the first place). Twitter is completely irrelevant to most people. They're vaguely aware it exists, but it really doesn't matter.

In TFA, you can see each tweet getting a few hundred to a few thousand likes/retweets, and most of those identified by the analysts as bots. So each tweet is maybe reaching an audience of a couple hundred humans, at best (and it'll be the same few hundred humans for all such tweets). How many of those humans are going to change their vote because of that tweet?

It's irrelevant.

But it is dangerous. Politicians get very nervous about elections. If the politicians are persuaded that any of this matters, then they'll be more inclined to stop it mattering. And that means laws that curb free speech online, monitor communication, prevent encryption, and all the rest of the shitstorm we're facing.

<comment><USER3> You should probably relay this information to those spending huge amounts in advertising.

<comment><USER2> I have a good friend who spends millions of dollars in advertising every year, and who is convinced that almost none of that has much impact on customer behaviour.

There are exceptions, of course, and advertising can be effective, but there is a lot of wasted money spent trying to persuade people of things.

</comment></comment></comment><comment><USER4> It's useful to know details such as these, but the bigger problem is that the audience that most "enjoys" and retweets this stuff honestly doesn't care that it is false.

I personally know people that, when provided clear evidence of entirely false and manipulative stories will justify them by saying, "well, this story may not be true, but there are a lot of stories like this that you haven't seen which are true".

The point is, they believe what they want to believe, and no amount of proof to the contrary will change their mind. In fact, they often just double down on their arguments.

<comment><USER5> Sure, that's normal human pleasure from having their beliefs reinforced. It's probably and even bigger problem for vague unfalsifiable ideas like "police are racist", "capitalism is evil" or "immigration is bad". If a news story appears to support such a belief, the person will have their belief reinforced, even if it's wrong and the (true) news story is an exception. One photo of an immigrant vandalizing a statue or one photo of a border guard making a child cry says "See? You were right! That whole political party is bad!".

</comment></comment><comment><USER6> It feels like 2016 all over again, with (some) people desperate for an explanation for why things happened the way they did which doesn't involve people holding ideological differences than what's found among the elite.

</comment><comment><USER5> That's interesting to analyze and everything, but it's surely inconsequential compared to what real people say and all their misinformation, rhetoric and general bias. What's the difference between a popular influencer with a public persona spreading politically biased stories and an faceless account doing the same thing?

It sounds like they're looking for someone to blame for right wing candidates' success in the same way people blamed Russian bots for Trump's success because they can't believe that real people could possibly be voting for such obviously "wrong" candidates of their own free will and they must surely have been fooled into it by clever tricksters.

<comment><USER7> Didn't the FBI and the Mueller report pretty thoroughly lay out the massive scope of Russian social media influence on the 2016 election and beyond? I thought this was a decided issue but maybe I'm wrong.

<comment><USER8> The report is publicly available here. [1] This is mostly covered on pages ~22-26. Quite a short read since it's redacted like crazy. The 'massive influence' seems to have been a company that setup some fake accounts on Facebook with a total advertising spend of $100k, and one that also had a few thousand spam bots on Twitter that 1.4 million people had "been in contact with" \- a phrase which was left undefined.

[1] - [https://www.justice.gov/storage/report.pdf](https://www.justice.gov/storage/report.pdf)

<comment><USER9> Thanks for the link, but it mostly disproves your dismissive attitude: according to the report, posts generated by accounts controller by the Russian company reached 29 million people on Facebook alone (and " may have reached an estimated 126 million people."), with hundreds of thousands of direct followers for several individual accounts. That is not nothing.

<comment><USER10> It's not nothing, but it's interesting to note that the amount they spent is dwarfed by the amounts currently being spent by top democrats (and Trump's re- election campaign), several of which are in the low millions of dollars.

> According to Facebook, the IRA purchased over 3,500 advertisements, and the > expenditures totaled (sic) approximately $100,000

I think everyone would like to know how much actual influence it had in the election but I'm not sure we will ever know definitively.

</comment></comment></comment></comment></comment><comment><USER11> racist prejudice displayed in this article is nauseating. seems users from certain asian countries showing interest in european politics automatically become members and proof of disinformation campiagn. shame!

</comment><comment><USER12> Interesting how bad twitter is at banning fake accounts. However, 200 russian bot accounts are not responsible for the populist shift in european politics, which is what a lot of people want to believe.</comment>


What Firecracker open-source means for the serverless community - <AUTHOR> https://serverless.com/blog/firecracker-what-means-serverless/ <comment><USER2> Who uses FaaS successfully? O get it for very bounded use cases, but was never able to really get a ton of use out of it other than gluing different AWS things together.

<comment><USER3> I've successfully used on-prem fn as a connection layer beneath API gateways and ESBs, but for cloud projects every time I use them (regardless of the provider), I end up swapping them out for microservices before too long. Deployment and management have always lagged far behind on-prem solutions.

</comment></comment><comment><USER4> well summarized !</comment>


Manager Can't Code? They Shouldn't Be Your Manager - <AUTHOR> https://qvault.io/2020/07/14/your-manager-cant-code-they-shouldnt-be-your-manager/ <comment><USER2> Managers should be technical enough to understand what is going on, but claiming that an effective manager needs to be coding 80% of their time (as the article says) is idiotic. Why be a manager at all at that point?

I've personally had _much_ worse experiences with managers who wanted to micromanage every technical decision and every line of code vs. those who just trusted their team with it and focused on people management, clearing organizational blockers, roadmapping, project management, communication to executives and other stakeholders, shielding us from company politics and lots more.

<comment><USER3> To be exact, the article said

> coding, architecting, or doing technical work that requires engineering > prowess.

As a software engineer, I don't even spend 80% of the time working coding, in fact it's more like 30%. But I do spend almost 100% of the time doing the stated things above.

However, I do agree with you (mostly). My position is that having an understanding of computer science make them much more efficient in the activities you described, some of which falls into the stated camp. Micromanagement is universally regarded as bad.

<comment><USER2> Still, all those should be the responsibility of senior engineers on the team, not management.

<comment><USER3> I think you have a point. But should making decision that require an intimate understanding of the technical stack be part of those activities? Should drafting new features be considered under architecting? I understand that my managers are heavily engaged in these activities and their decisions are challenged by very technically minded people before they are put to work.

<comment><USER4> New feature requests are certainly within a manager's purview, but designing how those features are implemented is not - that's your engineer or architects.

Of course, if your organization expects a manager to also be a tech lead, that's something else entirely (and not common in most non-startup companies).

</comment></comment></comment></comment></comment><comment><USER5> I believe the author of the article is confusing "manager" and "tech lead/senior developer". I think the author has projected things they think are important in a manager onto the roll and those things probably don't align with what senior stakeholders think are important.

I would certainly expect the technical lead to do a good amount of coding in addition to design and mentoring, but expecting the CTO to code as the article suggests seems wrong. I guess this might be true at a 25 person startup, but I think this is an unrealistic requirement for larger organizations.

By a similar argument, would the COO be reasonably expected to work on the assembly line and repair hvac on a regular basis? Again, perhaps at a company of 25 but seemingly (to me at least) absurd at a larger company.

<comment><AUTHOR> I'm certainly blurring the lines a bit, but I would argue that in most cases there isn't a need for both. The tech lead can be the "manager".

"Managing people" isn't a full time job in most cases. It all depends on how the organization is structured and how many non-technical tasks are being assigned to the "manager". Sometimes a manager is responsible for product, marketing, or HR tasks and all that will be dependent on the company in question.

<comment><USER6> A managers job isn't necessarily to manage people but outcomes. People are essential for that, of course, but there's often a lot of other moving parts to it that warrant a full time manager. The problem is often that building a good management structure is not only extremely difficult but also exceedingly rare, meaning many of us have either worked with bad managers or with managers that were poorly equipped to do their jobs effectively.

</comment></comment></comment><comment><USER7> I don't know about this. For me it always boils down to "it depends". I've seen situations unfold where a non-technical manager steps into a technical clusterfuck and promptly sorts out the mess in such a way that makes everyone happy.

I've found that simply by being an expert in some area, it can be extremely difficult to let certain things go and refocus on other objectives.

For me, there is definitely some yin-yang balance between the technology and business evangelism. Having 2 different humans with 2 wildly different perspectives many times yields a far better result than 2 different humans with 1 unified perspective.

<comment><USER8> You're correct, but I think the other argument is correct as well. I've seen teams where a manager is so technically incompetent as to be useless in their role. I've also seen teams where the developers were caught in technical minutiae while not contributing actual business value. I don't know if there's a cut-and-dried answer here.

<comment><USER7> One other way I look at this is as a balance of forces between technology and business. The developers are delegates to the technology while managers are delegates to the business. Assuming they can both arrive at some common middle ground, then you should have something viable to work with.

Sometimes I have to stop my other developers from getting upset with project managers when they are having bad days. If your managers are unhappy, it's very likely that the customer is unhappy as well. Developers should use this as a signal that they may want to re-prioritize efforts or schedule deep-dive meetings with their managers to sort out customer & business concerns.

The exact same idea applies to the technology. If the developers are in a bad mood, its quite likely that they are struggling with some abstract technological foe such as a legacy code base or broken devops process. Managers should recognize this as an opportunity to pause the process and try to allow room for the developers to work through whatever technical difficulties they are having.

If you have this perspective where everyone involved is a delegate to some other ultimate authority, you may develop a greater sense of empathy for your fellow human.

<comment><USER8> I agree, it mostly boils down to "human" or organizational problems. Technology or code problems aren't stressful in the absence of stress from the organization (time pressure / higher expectations than the team can deliver, etc).

</comment></comment></comment></comment><comment><USER9> Attitude is key here. My manager hasn't written non-trivial code in ages, but is deferential to my team when we provide estimates around how difficult something will be to implement, or how long it will take.

> Contrast the idea of a competent boss with the all-too-familiar experience > of going to a non-technical middle-management type with an engineering > problem, only to be stuck in a teaching session because the boss has never > heard of a pub-sub system.

Since we're being reductive, why not posit that if you can't explain your systems to someone who doesn't write code, you shouldn't be building such systems?

<comment><USER10> > _Since we 're being reductive, why not posit that if you can't explain your > systems to someone who doesn't write code, you shouldn't be building such > systems?_

If we _really_ want to be reductive, then there's no reason to hire a manager that shares a language with their subordinates, because if you can't teach English to someone who hasn't learned it, what business do you have talking? Clearly, this is absurd, which means there must have been some reasonable grey areas that got left behind along the way...

</comment></comment><comment><USER11> Legitimately confused by this. Is it really common that truly non-technical, as in can't write code at all, people are managing Software Engineering teams? I've certainly never seen it, at least until you get to Senior Exec levels of leadership. I've only been in the industry for <10 yrs but I still find it hard to believe it's that common.

<comment><USER12> There are non software companies with software teams

<comment><USER11> Sure, I work at one. But my manager is a former tech lead/architect who writes code everyday and he reports to a former Startup CTO with a CS Degree from UIUC. Are English Majors with no tech chops seriously managing engineers in 2020?

<comment><USER13> MBAs, mostly.

</comment></comment></comment></comment><comment><USER3> I agree with the gist of the article. The point is not to throw manager into actual coding task, but for them to have a background understanding of how everything works either through formerly being a software engineer or $(multiple ways one can educate oneself on the principals of computer science).

My anecdotal evidence have strongly pointed that for a software project, managers that have an understanding of computer science have a strong edge on communication and decision making.

</comment><comment><USER14> Alternative POV: if they're not an engineer, then they NEED to be good at something else. I can imagine a situation in which a really excellent, organized, project manager with excellent ability to run interference with other teams/management was a valuable manager. This seems that the argument is more like, "Managers who do not code should not pretend they know how to code". Maybe, in that situation developers should look for technical review / help from their peers on the team?

</comment><comment><USER15> Hard disagree. Some of the best managers I've had are non-coders. I think a technical manager needs to be able to understand technical concepts at a high level, but actually writing code? Nah.

(Some of the worst managers I've had, contrariwise, were people who started as coders and kept trying to work their decades-old knowledge into conversations. No, this service didn't "ABEND," thanks.)

<comment><USER16> As a kind-of technical person (tech degree with limited professional application), I think you're exactly right. After going tech role > non-tech role > non-tech-but-managing-tech role, I found it was often most valuable for me to stay at a buzzword level. My team was always happiest when I could take their mostly-natural output and keep the monkeys off their back.

</comment></comment><comment><USER17> I find it really rare to find managers who regularly code. Even if they once coded, after a year of two of not coding and they've lost all context and familiarly with the codebase or tooling that they probably shouldn't be coding anyway. Managers should be technically competent but largely be neutral arbiters that encourage and support their teams (ideally you have a 1 manager:2+ team ratio or they tend to micromanage). They should really only be making technical decisions if the team is deadlocked and there needs to be a tie breaker (which should be relatively rare and it's likely both directions are reasonable at that point).

Senior engineers should be kept around to mentor younger engineers to provide that valuable feedback and there should be a career path that doesn't require them to go into management (a lot of companies try to do this but I've never seen it done well and the managers always seem to have broader reach, better compensation, and more promotion opportunities).

</comment><comment><USER18> I've only experienced a non-technical manager once - maybe this more common in older, more traditional companies.

I don't agree that a manager should spend 80% of their time coding, though. Maybe for smaller teams at early stage startups. But for even a team of 4-5, there are typically things they should be doing that are a better use of their time. It helps to code part of the time (maybe 20%) to understand the codebase, your level of technical debt, and proposals from engineers, but coding can be a trap that keeps you from doing what you need to do to enable your team.

In a worse case, technical managers can become micromanagers, and their opinions can have so much outsized influence that they lead to bad decisions.

</comment><comment><USER19> In software, I think that there is a qualitative difference between managers who _have programmed_ \- at any level of experience, even if it was a long time ago- and those who have not. Some exposure gives them a more realistic notion of what is hard, what is easy, and what is bullshit.

Beyond this, programming skills and specific technical knowledge can be useful as a manager, but I'm dubious that they are as essential as this article implies.

I further imagine that a similar pattern holds for other technical fields- you need some basic grounding, but do not need to be a technical expert to manage.

</comment><comment><USER20> This rubric is fine at a certain level of scale, but as a company grows, both in size and complexity, it becomes hard to apply except possibly in the leaves of your organizational graph (and not always then).

Personally I manage a team of 400+ engineers. They do the full range of embedded systems across multiple platforms, iOS and Android native development, full stack web development, backend systems, and data science. We go all the way from device drivers that are deployed to 10's of millions of devices to Spark jobs running in a reasonably scaled up cloud infrastructure (5 digit CPU counts, not 6 or 7).

Needless to say, I am not competent in all of these domains. I do my best, and when decisions get to my level I know how to make them in a way that doesn't leave me as the weakest link, but fundamentally I can't possibly be an expert in all of what we do. There aren't enough hours in the day or days in a life.

Compounding that problem, at this level of scale, I believe in cross- disciplinary ownership. We don't have an iOS team that throws things over the wall to a site team, or a FW team that only thinks about how to optimize their part of the world. That means many of my managers are also managing engineers who know orders of magnitude more about their discipline than the manager does. It turns out this would happen anyway, because the manager shouldn't be making most of the technical decisions, and they don't have enough time in the day to stay expert in even one discipline at the level a senior IC is expected to.

You can't expect your managers to be the ultimate expert across the domains they manage, and even if they happen to be, you can't expect them to be able to keep that position (our industry changes too rapidly). What having been a practicing engineer does for them is to give them a perspective on what matters, to ask the right questions, to help the team develop an ownership culture so that they don't rely on the deus ex machina of a manager know-it- all who tells them what to do. Very few of the skills they need relate to having been the best Javascript engineer on the team at some point in time. They need to know how to _develop_ the best engineers, not continue to occupy that role themselves.

Last thought here -- this compounds when you get promoted into a role of managing managers. For many managers, this is a harder transition than moving into management in the first place.

<comment><AUTHOR> Great insight, thanks for sharing. I believe your example is a good one. I'm still a believer that someone in your position should have a solid understanding of the architecture of your system, and likely experience with at least a part of it. That doesn't mean you need to be an expert in every domain, obviously, as that would be impossible.

</comment></comment><comment><USER21> I'm curious about a related question: Does a manager need to be the best coder on the team? How much does it help/hurt if they're not?

<comment><AUTHOR> No, but IMO they should be one of the more technically competent people. Managing is not a full-time job, at least for a good manager its not a full time job.

<comment><USER22> I think you're underestimating how much work there is at the management level, especially in larger organizations. When management is doing their job, it won't be visible to you or your team. Things will just "align", and work well - but if things are moving smoothly in an organization with multiple teams, your management is working well.

There is a lot of systems thinking required in managing team structures, interfaces between those teams, managing communication between teams, hiring, setting technology standards & architecture, and so on (review the rest of this thread).

I do agree with your thesis though - a manager should be highly technical. I just don't think you can depend on their contribution to features & deliverables. Not because the work is "below" them, but because Engineering Management is a support role and should NOT need to choose between an IC-type task and helping unblock/support a member of their team due to a deadline :)

</comment></comment></comment><comment><USER23> >"In this study from Harvard 35,000 employees from the US and Great Britain were polled about their job satisfaction, and metrics were gathered about what influenced their happiness at work.

The results showed that

 _the single greatest influencing factor on employee satisfaction was whether or not their boss was technically competent._ "

</comment><comment><USER24> I have been thinking about something else. What is the exact function of a manager other than the annual reviews and hiring? I would like to ask the managers here, what does your day to day look like? How involved are you in the technical things your team does?

<comment><AUTHOR> Author here: this is something I wonder often. In companies I've worked at that had non-technical leadership in the engineering department I'm suspicious that they just played Bloons TD 4 all day. They certainly never seemed to have anything to do other than hire, fire, and go to meetings to have things explained to them.

<comment><USER16> That's not it at all - a year ago, we actually defined a new strategic initiative to migrate the legacy userbase to BTD5, and the CEO herself gets regular readouts.

</comment></comment></comment><comment><USER25> So Steve Jobs shouldn't have run Apple?</comment>


It's Time to Play Moneyball: The Investment Readiness Level - <AUTHOR> http://steveblank.com/2013/11/25/its-time-to-play-moneyball-the-investment-readiness-level/

<comment><USER2> You can't over generalize startups like this, every startup has different obstacles a different business model, market, etc. You can't just box them and show the metrics as if they are all the same, they will learn to game your system very quickly which has them working towards a very different goal than ultimate success. Also, this system seems like an unnecessary hassle, all the time spent here will detract from the time spent creating value for the company.

I am all for a more metric based investment philosophy in the industry, revenue/profit might be a good place to start..

</comment><comment><USER3> Random question: Is it correct to call it readyness or readiness and if so, why?

<comment><USER4> The usual form is "readiness". According to the OED, "readyness" went out some time in the 17th century. I think terminal "y"s quite often turn into "i" when a suffix is added (ready -> readier; daily -> dailies; thirty -> thirtieth); there is probably an interesting reason for this but I don't know it.</comment></comment>


Show HN: Relinx – new kind of Asset tracking – CMDB - <AUTHOR> https://relinx.io?ref=HN <comment><USER2> Can you say what database you're using? If I were to guess this is an application specific UI over something like Neo4J although it's not very specific and seems quite general.

<comment><AUTHOR> Database is PostgreSQL. I designed it to be general and flexible to be used in different fields

</comment></comment><comment><USER3> I think the hard part of asset management is getting the existing data into the tool, and then keeping it accurate. What are your plans to address this?

<comment><AUTHOR> You are right. We'll add Import data and also expose API to automate this task

<comment><USER4> You should first build agents that run on clients, or tools that remotely gather this inventory info via the network.

If you're thinking manual data entry will be the primary use case for an asset control /CMDB, you will lose _badly_ in the marketplace.

<comment><USER5> The problem is the support matrix which is crazy in this area. I think ServiceNow did pretty well without having too many adapters (of course now they have quite a few - [https://docs.servicenow.com/bundle/orlando-it- operations-man...](https://docs.servicenow.com/bundle/orlando-it-operations- management/page/product/discovery/concept/c_DataCollectedByDiscovery.html)). So if the product is easy to use, reasonably priced, and has the ability to schedule data imports, why not?

<comment><AUTHOR> Yes, the focus now is to validate the concept and make an easy-to-use and flexible product

</comment></comment></comment></comment></comment><comment><USER6> Pricing?

<comment><AUTHOR> Thanks for your interest in Relinx! Relinx is and will be free for personal use. "Corporate" features like Workspaces, Sharing, Permissions, etc will be added soon and based on a monthly subscription about 5$ per user/per month</comment></comment>


From dependency injection to dependency rejection - <AUTHOR> http://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection/ <comment><USER3> This reminds me a lot of Gary Bernhardt's _Boundaries_ talk and the associated idea of "functional core, imperative shell". For anyone who found this article interesting, you might also like this: [https://www.destroyallsoftware.com/talks/boundaries](https://www.destroyallsoftware.com/talks/boundaries)

<comment><USER4> Thanks for sharing that. That's a great link, and I agree, they are talking about the same thing and reaching pretty much the same conclusion. The talk is well worth checking out.

</comment></comment><comment><USER4> Very good article. If you think about it, you will see this pattern in many places. Simply because it is the outcome of emphasizing pure functions.

For example, it's the heart of the virtual DOM in React. Pure functions create an entirely new (no mutation) virtual DOM, and then something at the "impure boundary" applies this to the actual, messy, mutable DOM of the browser.

With a little thought you can probably find several other well-known examples.

</comment><comment><USER5> It's interesting -- this is not what I generally end up using DI for. The point of DI, a lot of the time, is to put seams into the program where you can test units of a limited size. If you don't have some way of injecting behavior, you end up having some serious trouble when you have a module that brings together the behavior of many sub-modules (how do you test it?). That's something these short code example style articles never seem to capture for me.

<comment><USER6> Why not test the whole thing together? That's what it was meant to be - <USER2> whole.

<comment><USER7> 1\. Speed of automated tests. 2. Often it is good to test the semantics of a sub system are solid before integrating it so that edge cases are routed out and at the very least it's easy to find where a break occurred.

<comment><USER8> 3\. You might have external dependencies that are difficult or impossible to duplicate in your testing environment. Yes, stuff like this exists -- e.g. a medium-size retail bank will have at least a dozen, typically multiple-dozens of external contractors, each with their own APIs and testing environments.

<comment><USER6> This is the only answer that speaks to me. Although I would think most often you would have such dependencies be API calls over network. It would me more prudent in such case to create a mock server rather than use DI. But yeah, in general API from a third party might call for DI. Thanks.

<comment><USER7> > only answer that speaks to me

So what if a dev home brews parser for instance, and you use that to read in files from a legacy system via ftp. You wouldn't test the parser code on its own? You test it all end to end?

<comment><USER6> If it's just a parser you need to test, there is no need for DI - just give the parser some files to chew on, and test it directly.

If the "parser" has built-in logic to orchestrate remote file retrieval over FTP then DI is warranted, as per the other part of my previous answer.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Two things:

1\. This is overly simplistic. What happens if your IO and logic are by necessity interleaved? Grab X out of DB, grab Y or Z out of DB depending on X's value, etc.? The whole thing just reeks of "ideal case".

2\. This is overly complex. All that really needs to be said here is "pull out your pure code when possible". There's nothing special about F# to enable that. The logic in "tryAcceptComposition" is just a function calling other functions; you can do that in C# or even C. The only advantage F# adds here is the piping syntax, which to me only serves to make the code more obtuse. But I guess you couldn't write a three-part series about a single "extract pure function" op.

(This brings up an interesting thought: ReSharper should come up with a way to let you highlight a function and extract the "obviously pure" tidbits automatically).

<comment><USER10> You may find it interesting to go over a similar conversation I had with the post author a few days ago [https://github.com/ploeh/ploeh.github.com/commit/f89c405e92b...](https://github.com/ploeh/ploeh.github.com/commit/f89c405e92b69c4dfcc65c336a0ff4528f50f029#commitcomment-20681176)

<comment><USER9> I'll have to learn more about free monads. In general I love F# for doing domain modeling and logic, but I still find OO-style DI better for organizing "services". I've followed ploeh and scott wlaschin for some time and all my attempts to use their DI concepts in my own real-world code have led to code that's less intelligible than IoC with no tangible benefit. It's not for lack of trying, and I _think_ not for lack of intelligence. It just never worked for me.

If free monads could provide something better than standard DI, and (and this is a big caveat) still retain decent editor integration (autocomplete, go-to- declaration/implementation), then I'd check it out. But my gut feeling says that it'll end up being a leaky abstraction that will need undue patching up just to maintain it.

<comment><USER11> F# uses .NET classes and objects for a module system, so your use of Objects for "services" is not surprising. An OCaml programmer is much less likely to miss Objects and DI frameworks, as OCaml has a powerful module system (i.e. module functors).

Free Monads can reify an effectful computation, giving flexibility on how it is interpreted. But they are not really a substitute for a good module system.

<comment><USER9> Okay I think I get free monads now. They seem pretty awesome, essentially letting you plug in an interpreter for the function you're going to run. I can see high-level how this would appear to be a great generic DI option--you set up an "interpreter" to handle the statements in your function however you want: for reals, for test, for reals with logging, etc. And automagically everything gets executed exactly how you want with no additional cruft.

What makes me cautious about the concept though is that e.g. `do_x_and_y()` would be interpreted differently than `do_x(); do_y()`, even if they were fundamentally the same. While "so what?" is a perfectly valid response, that little tidbit just makes me feel like, while FM's are a very cool abstraction for _something_ , it's not really ideal for DI. It's just something meant for a different level. The article "The Wrong Abstraction" comes to mind.

<comment><USER10> > ... you set up an "interpreter" to handle the statements in your function > however you want: for reals, for test, for reals with logging, etc.

That is the tip of the iceberg of free monads. Their full power lies in being able to _combine_ different type sof effects into more powerful, composed effects. E.g. you want to do IO while also processing probability distributions using a probability monad. But they can get pretty hairy. See [https://youtu.be/qaAKRxO21fU](https://youtu.be/qaAKRxO21fU) for the gory details.

</comment></comment></comment></comment></comment></comment><comment><USER12> The key part about why dependency injection with partial application is not functional:

> When you inject impure operations into an F# function, that function becomes > impure as well. Dependency injection makes everything impure, which explains > why it isn't functional.

</comment><comment><USER13> It seems that in the end the initial function Post(ReservationRequestDto dto) has to call the tryAcceptComposition which has its dependencies hard coded there. So how exactly this solved the issue?

If you pass the dependencies as parameters in the tryAcceptComposition function, the Post would have to know its dependencies and we would be back to the initial state.

I would like to know the whole example he showed before using this model to see how this scale for more than one function.

</comment><comment><USER14> Nice! An alternative is to try something like SimpleMock [http://deliberate- software.com/simplemock-unit-test-mocking/](http://deliberate- software.com/simplemock-unit-test-mocking/) which strikes a balance between useful and easy to test. Also there's examples in F# [http://deliberate- software.com/f-number-unit-testing/](http://deliberate-software.com/f-number- unit-testing/)

</comment><comment><USER15> More evidence that functional programming is a useful simplification/complexity reduction on a number of older paradigms.

<comment><USER10> Functional programming is actually the older paradigm (if you're comparing to OOP), but I get your point.</comment></comment>


GPD WIN 2 - <AUTHOR> http://forum.gpd.hk/t190-gpd-win-a-handheld-game-console-that-can-run-aaa-games-smoothly <comment><USER2> Am I reading this right, that this is a handheld device more powerful and capable of doing more than my current laptop on its best day?</comment>