Coding as an Engineering Manager - <AUTHOR> https://nemethgergely.com/coding-as-an-engineering-manager/ <comment><USER2> I think a lot of organisations (and people) fall into the trap of thinking of an engineering manager as a more senior tech lead, when in fact they are very different jobs with very different modes of working.

As soon as you start taking on managerial work, your development productivity starts to fall rapidly. I've never found a happy medium, nor have I seen others achieve it. People who try to do both quickly settle on ~80% of one and ~20% of the other. Which is fine if you acknowledge that you can only do ~20% of the other, and that the shape of it is likely to look very different to when you were spending 100% of your time on it.

As others have mentioned, if you are an engineering manager and you still want to dedicate some of your working time to development, you have to take yourself out of the critical path. Nobody wants to hold up a release because you were working on an important part of it and you've been constantly interrupted all week with managerial work and meetings.

Instead, pick things that are either tiny or decoupled from the release process. Things like refactoring, non-critical bug fixes, documentation, tests, spikes. These are the kinds of things that won't fall apart if your development productivity is unpredictable and the kinds of things that are easy to put down and pick up again. As an engineering manager, you're interrupt-driven which is incredibly disruptive for focus. If you do write code, then it has to be the code that works within those constraints, or you'll end up being a blocker for the rest of the team and your managerial work will suffer as well.

<comment><USER3> Agreed with everything you said, and will add 2 major points:

1) God help you if you choose 80% coding and 20% management. Your team will be very unhappy. Maybe you'll take care of the HR/Admin work that noone else can, but their career growth will stagnate, and morale will be low.

2) If you do pick 80% management, and 20% engineering, understand that your growth as an engineer will completely plateau. Yes, you can still participate in design reviews, even weigh in on code reviews, and ship the occasional bug fix/perf improvement/nice-to-have feature or some operational tool that will save your team a bunch of time and make your oncall happy.

But without hands on struggle with a new paradigm or scaling challenge, you won't grow. And given the choice between improving as a manager or improving as a hands on techie, you have to make the choice to work to improve as a manager, and start doing all the invisible things you never realized a manager does (least known and most annoying is managing UPwards)

SOURCE: Just spent a year stepping into a vacant engineering manager role on my team, tried to do the 80-20, didn't love the management role, am back to a full time senior engineer, and am frustrated with my skills that appear to have atrophied.

<comment><USER4> what kind of managing do you do ? I dont spend more than 1 hour a week with my manager, so I am not sure where your time goes ?

<comment><USER2> Off the top of my head, these are the kinds of things engineering managers often have to deal with:

Hiring:

\- Writing job specs.

\- Dealing with recruiters

\- Reading CVs/résumés

\- Interviews

\- Onboarding

\- Outreach

\- Who do you need to hire next quarter to avoid capacity problems?

People:

\- How do you level up your developers? What new responsibilities can you delegate to them so that they can grow without swamping them? Are you available enough to them so you can help them take these new tasks on?

\- Evaluating training courses / conferences etc.

\- Are there any personal or interpersonal problems that need sorting?

\- What can you do to help your team gel better and feel like they are part of a team?

\- Where are your team members' careers heading and how can you help them get there?

\- Your team has grown too large to manage effectively by yourself. How do you split things up?

Process:

\- What is everybody working on? What will everybody work on next?

\- What are people blocked on? How do you unblock them? What is likely to block them next?

\- Can you do things in a better way? How?

\- You've got a lot of bugs in the backlog. Is there a root cause? Are there any patterns?

\- You aren't performing as well as you thought you were. Where is the time being spent? What's the cause? Are the estimates wrong or the performance?

\- Some people want to shift their hours or work remotely. Can you accommodate this? Do you have to adjust process and if so, how?

Line management:

\- Approving invoices

\- Approving holidays

\- One on ones

\- Salary review

\- Getting people back to work after sickness / parental leave / sabbaticals

\- Disciplinaries / performance problems

\- Firing / redundancies

\- Exit interviews

Planning:

\- How well is your team performing? How do you measure this and how do you improve?

\- Do you have enough capacity?

\- If not, which features do you bump?

\- Are there any bottlenecks in the pipeline?

\- What are you telling the shareholders you're delivering next quarter?

Product:

\- Does marketing know what you are building next? What information do they need from you to sell it?

\- Do CS know how to support your customers with the new features?

\- Feedback from the rest of the business about the product and how the tech team works.

\- Are the specs precise, correct, complete, and achievable?

\- Features have been requested. Are they technically feasible? What's the general size of it and what quarter can we deliver it by?

\- A big customer has a major problem with your product. It's not your fault, but it has a disproportionate affect on the customer. How do you prioritise solving this problem?

External:

\- A shareholder owns a business with a related product that they want integrated ASAP. How do you deal with that pressure without disrupting your plan?

\- One of your suppliers has a data breach that has leaked your data. How do you deal with that? Have you defined processes for reporting security issues?

\- A supplier is failing to perform adequately. Can it be fixed? How do you move away? How soon? Where does the work fit into the schedule?

\- A supplier has changed their pricing structure. Do you have to move? How soon? Where does the work fit into the schedule?

\- New legislation has been passed and you have to make changes to your product. What are the requirements?

\- A complaint has been made about the accessibility of your product. Does it have merit? What's the impact of fixing it, and how urgent is it?

\- A big prospective customer is on the verge of signing, but they must have one feature that you weren't planning on building until next year. How do you rearrange things to get the customer with minimum impact?

\- A service you use is changing their API. What's the risk of staying on the deprecated version until it can be planned in?

<comment><USER5> Amazingly thorough list. Did you compile it from your experiences? What field of engineering are you involved with? Hopefully you did not experience all these problems personally.

<comment><USER2> Yeah, virtually all of it is from personal experience, although the most negative ones are fortunately rare! I manage a team working on a platform that lets non-technical people build communities through web & mobile apps, so the tech we're dealing with is roughly Rails / PostgreSQL / VueJS / Swift / Kotlin / AWS and you could loosely describe us as a social media startup.

I guess if I could summarise the above, it's that there's an awful lot of very ill-defined and irregular things that need deciding about and acting upon, and it's an engineering manager's job to corral that into some sort of order and make sure it all happens. Lots of spinning plates and dealing with things that don't really fit neatly into a job description, especially at smaller companies.

</comment></comment></comment></comment></comment></comment><comment><USER6> I used to be dislike the idea of being an engineering manager and wanted to stay in the code. Interestingly enough, having children completely changed my perspective on management. Some important management skills - e.g. patience, delegation (babysitters!), investing in someone's overall productivity and long-term success (Schools! Extracurriculars! College!), prioritization (family comes first!), sometimes cleaning up after someone else's messes (with kids, literally!) - come from being a parent.

I'm half joking, but only half! I believe part of being a good engineering manager is having had hands-on software development experience so as to better keep a check on velocity, code quality, and overall tech decision-making. Much in the same way, I feel like I can be a good parent and can teach my kids how to process their world because I've lived it before.

<comment><USER7> Having a kid during my transition to management (in the absence of existing management) brought me to the exact same thought process, and it's a dead-on observation I live every day six years later. It becomes much less about the executional skill, and much more about the aspects you listed above. The skills involved in parenting and managing are one big feedback loop of sorts.

Having someone that can see the forest for the trees and chart/change course as a team is, additionally, crucial. It's just that, at home, it's not just me.

</comment></comment><comment><USER8> I always make sure I can still compile and execute the code. If I can't, I get someone to update the README files so that I can. That also helps me make sure new members can be onboarded.

I also do off-critical-path features and bug fixes. That said, I did write a fair bit of the code base before taking a more managerial role, and I contribute to discussions about what will make the thing faster.

<comment><USER9> Compiling and running your team's code could be the most powerful excercise to stay connected with the engineering part. Way too often I would discover that some functionality declared as 'done' cannot be demonstrated in any way, and such discoveries initiate discussions leading to meaningful decisions.

<comment><USER8> Yeah exactly. I see it as a form of QA. It's not serious if discovered early, but I've come across times when there was some new dependency I didn't have, forcing me to google how to install it. So then I tell the team and someone will update the docs.

Basically, if only the people who wrote something can compile/execute it, it isn't done.

</comment></comment></comment><comment><USER10> I've worked in organizations that promoted engineers into management, rather than bringing in outside managers or managers without engineering backgrounds. For highly engineering-driven orgs this can make a lot of sense, and depending on how it's done and the people involved, it can produce great results.

However: when those managers hold on to their engineering responsibilities, their teams suffer for it. There's a negative stereotype among engineers that managers don't do anything anyway, so maybe the team just needs a designated engineer to play manager in order to go to meetings, approve days off, etc.- the bookkeeping parts of management, but not the managing parts of management. There's a perception that the other engineers on the team are super self sufficient, what do they need a manager for anyway?

Often these managers would be allowed to continue doing engineering as a motivator- they didn't really want to be managers in the first place, let's just let them keep doing their thing and throw some more money at them and everybody will be happy. But it really feels like an antipattern.

Working on different teams where managers didn't do any coding was a breath of fresh air. I didn't know what I was missing. Managers can do the most good by focusing on things that allow their engineers to be as focused on their work as possible, and as unblocked and undistracted as possible. It makes a huge difference. It doesn't matter how incredibly self-sufficient an engineer is...if they get stuck doing a bunch of extra non-engineering stuff because their manager doesn't manage, their work and happiness will suffer for it.

So, at least based on my own experiences, I've come to see teams where the manager still has engineering responsibilities on their own team as a red flag. Anecdotal and highly contextual to where I've worked, but that's been my experience.

<comment><USER11> Can you provide specific examples of things that you found the most useful when you finally had a full-time/non-coding manager? Having somewhat recently transitioned into an engineering management role, I'm curious if there's anything (or situation) in particular you'd highlight.

<comment><USER10> This is all in the context of large tech companies, so YMMV. Things like, going to high level meetings so engineers don't have to, and making an effort to keep engineers from getting sucked in to too many meetings period (at least, ones where their presence isn't critical).

Helping with bug management and task prioritization, minimizing engineers' multitasking to maximize productivity, and guiding the team towards long term goals. Engineers tend to be super focused on their immediate and short term tasks- what they're supposed to be doing right now. That can make it hard for a team to collectively maintain trajectories towards long term goals over the course of months and years. IMO a good manager will be the ultimate maintainer of the long term goals, and can helpfully keep everyone on track as they individually focus on shorter term stuff.

Also, enabling their engineers' professional development. Many engineers really thrive when they're tasked with something that involves learning and using some technology that they don't know, but are curious and excited about. As much as possible, if it aligns with team goals of course, it's great if people get a steady trickle of these kinds of tasks. Only if they'd want them, of course. It feeds their curiosity and creativity, and helps the whole team keep their technical edge. But these things are unlikely to happen unless the manager picks up on the interest and potential, and explicitly tasks someone to do it.

Finally, it might sound silly, but making a point to do pleasant team building stuff like bringing in bagels or donuts for everyone once in a while, or having the occasional team lunch at a cool restaurant (assuming there are cool places nearby). Also t-shirts. :) Quality t-shirts provide a surprising amount of bang for the buck in terms of goodwill, at least in large tech companies.

<comment><USER11> These are great; thanks for the insight!

</comment></comment></comment></comment><comment><USER12> We don't let managers code where I work. We also don't let them do anything technical besides match employees to work they want to do. Your manager is just there to make sure you can focus as much as your time as possible being productive.

I really like this approach, it's extremely bottom up. It's not that I think our managers don't have technical skills. They all have impressive backgrounds as SWEs etc, but this setup is for the best. The alternative at other companies I've worked for ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions, and managers who intertwined their management success with the product and drove it to ruin because they weren't making the best technical decisions for the product.

So please, if you're a manager, stop coding. Manage people, unblock them, make sure they are happy. Empower them to do the coding for you.

<comment><USER13> "We don't let managers code where I work."

"...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"

There's a connection here. A technical manager can't make reasonable tech decisions unless they do some tech work, but perhaps we just need to be more clear that what you want is a pure project manager to check off boxes.

I think a good tech manager still respects a bottom up approach most of the time, but should have enough experience to push back when the group is steering in the wrong direction. A generic project manager isn't going to do that.

<comment><USER14> I've had a primarily technical career so far and am working on switching to engineering management in the foreseeable future.

Once I'm done with that switch, I don't _want_ to be frequently making technical decisions, rational or otherwise - that should be the job of the tech lead on my team, with input from everyone else.

I will, of course, need to remain technical enough that I can understand whether my tech lead is making good decisions, as you say. I'll also need my team to respect my credibility enough to know that I relate to what they're dealing with, and to be able to effectively keep them unblocked.

But none of this requires sustaining continued technical contributions within my day job past the initial transition period, at least not once the company is above a certain size.

One of the best managers I've ever worked under (indirectly) was not technical and didn't pretend to be. What she did know was people and organizations.

When have you ever heard of a large org making a re-org to solve real problems after substantial consultation and with anything close to universal buy-in? She managed that, and well enough that she correctly used arguments from the rank and file to explain the re-org to other parts of the company.

That's the kind of mentor I'll want to learn from as a manager.

<comment><USER15> > I will, of course, need to remain technical enough that I can understand > whether my tech lead is making good decisions, as you say

A lot of stress has been created for teams I'm on by semi-technical managers chiming in. By telling yourself you'll remain technical enough, I'd encourage you to define what that actually means. Thinking you know stuff that you actually don't is going to be a huge pain in some one's ass.

I once had a boss who kept pushing for us to to do things in a certain way using a remote API, but the API client didn't support the features needed to do the things my boss insisted we use. The boss wouldn't allow for a discussion on extending the API client because he was 100% certain he was correct when he was in fact 100% wrong. I started looking for a new boss after that.

<comment><USER14> Completely agreed. Knowing the limits of one's knowledge and accepting feedback when one is misinformed are important skills. I believe I already do that and I certainly don't plan to stop.

If I have a competent tech lead under me, I wouldn't be pushing for a certain technical way to do things except if the requirement came from some external constraint like the business or another team, and I would accept the limits of technical possibility.

I might share my technical input if it happened to relate to my area of expertise in a way that wasn't otherwise sufficiently present, but I want my team to know their stuff, not to defer to my technical knowledge out of some personal need to be the expert. Also my input != final decision, with respect to technical decisions, if I'm not tech lead on the task.

Even if I had to push for or against something, I'd do my best to defer to my tech lead (i.e. not me) to actually come up with and lead the solution. It's not a manager's place to prevent a tech lead from conducting a discussion on technically how to achieve the goal within the applicable constraints.

</comment></comment></comment></comment></comment><comment><USER16> I really like the "work on bugfixes and small features".

There's lots of coding work that is easy to drop at a moment's notice and not mess up other work, schedules, etc.

Tooling is another one. Find processes that could use a nicer tool.

<comment><USER17> We have some managers that help in reproducing bugs. For me as a dev this is super valuable and saves me a lot of time I can spend on looking at the code.

<comment><AUTHOR> Oh that's a great! Are you okay with me adding it to the article?

<comment><USER17> Sure. The good thing about this is that they were often very good devs so their insights are really good.

</comment></comment></comment></comment><comment><USER18> I'm a CTO (of a company quite a bit smaller than Uber) and I do basically everything in this article.

One thing missed here (or that is out of scope of the article) which I think is actually very important is that engineering managers should get involved in QA. It's not glamorous but running through a couple of manual test scripts yourself gives you insight into features you might not know too well (if the product is very large) and also to personally assure yourself of the product's quality.

I find myself incrementally tweaking the QA test script every now and again when I do this, it's a great way to continuously improve the process.

<comment><USER19> Totally agree on the QA side, you need to see first hand what's coming out of your team to understand where your team is at.

</comment></comment><comment><USER20> I think people should be able to swing back and forth; manager for a year or two, engineer for a year or two. I don't believe everyone can be happy with a prescriptive path to follow -- I can't only be one or the other for the rest of my life. I like leading, mentoring, and developing teams. I also have strong inclinations towards inventing solutions and developing the future generation of technology.

I think businesses need to be able to adapt people to different roles and be comfortable moving people around and let them change over time. Otherwise we'll have people hopping off to new companies every few years as we tend to and taking all of their domain knowledge with them.

<comment><USER21> Great article on that here: [https://charity.wtf/2017/05/11/the-engineer- manager-pendulum...](https://charity.wtf/2017/05/11/the-engineer-manager- pendulum/)

</comment></comment><comment><USER22> Lots of anecdotes here...I'll add more.

I worked primarily in 2 type of companies as far as this topic goes.

The first (and in my sample, more common) kind was engineering managers as pure managers. You had tech leads which were really DRIs on technical projects, but very much software engineers in their day to day roles, and Engineering Managers which handled money, people issues, and made sure the tech leads did their jobs. At some companies, teams have both. Often each team has one TL and an engineering manager may look over multiple teams. Not always though.

That works, but there's a bit of a disconnect. The person who decides if you should get promoted or get a raise (or fired!) very much relies almost exclusively on second hand information. They may have been an engineer in the past, but they're not anymore, and may only have a loose understanding of what is truly happening. They're usually a bit better at handling people issues though.

The other kind is the "your boss should generally be able to do your job. Maybe not as well, definitely not as fast, but in a pinch, given enough time, they could". So engineering managers are just a higher form of tech leads that ALSO have the whole people/money/management responsibilities. They code (a little...maybe 5-20% of the time max) and can fully understand the problem the people they manage are dealing with (not just because they did it 5 years ago, but because they deal with them too in the present). That's a lot of work.

Much, much fewer people are qualified to do this so to scale, you either have to be a very competitive organization, or actively train/manage/promote engineers into those roles (or steal people from the rest of the organization and train them as engineers. That works too!).

I personally much prefer the later (even though another post mentions it as being a potential trap, I saw it work very well when handled properly). It's infuriating to have to explain to a manager that the company's darling engineer actually suck, but the managers only see the end result (without what happened to get there or without being able to analyze the cost) and have significant decisions be made around it. But again, it's very hard to build an organization that way.

<comment><USER23> >It's infuriating to have to explain to a manager that the company's darling engineer actually suck

Holy crap, yes. Well it's not always that the darling TL sucks but often that they themselves are in a role where they aren't familiar with some of the tech the people working in their team are working on, so they don't know how to properly make the large scale time estimates that get reported to the manager (and why would you ever ask the people actually working on specific tasks how long something would take? That makes too much sense and they might not tell you what you want to hear). But when they're the darling and you're working to meet the darling's time estimates that were never realistic in the first place, you get thrown under the bus to the manager when time estimates fail. This actually just happened to me today.

This power structure also allows the manager/TL to play good cop bad cop on their employees where all bad news/orders from manager to employee goes through the TL but all good news/orders goes directly through the manager.

You can't really win in a finger pointing game like this. The only fix is to just leave

<comment><USER22> > Well it's not always that the darling TL sucks

While I've definitely seen instances of the darling being a TL, my biggest issue is when its an individual contributor. I've had to deal with cases where the company's "ninja" was some dude who just hid in a corner pumping shitty code 18 hours a day, ignoring all pagers, requests for help, his teammates, or even his own TL. But he shipped software that kind of sortoff worked (well, as long as his teammates handled every pager notification that came every time it failed). Management loved him because of his "productivity" and hated how everyone else was so slow (because they were deleting with the fallout of his crap).

It was awful.

</comment></comment></comment><comment><USER24> Here's how I do it:

1) I manage a team of fullstack engineers where I do very few coding tasks but also can sometimes chip in on large efforts or when senior people are out of the office.

2) Code liberally on weekends and on my bus ride in the morning on OSS and a SaaS I've built over many years.

Staying engaged technically makes me unquestionably a better manager, but I will impede my team's development if I take tasks in the team sprint.

</comment><comment><USER25> This article is pretty close to my own situation. I've found that the worst thing I can do is work on features that could potentially block everyone, and the best I can do is grease our code ecosystem by updating libraries, compiler versions, and low level code which doesn't affect business logic.

</comment><comment><USER26> Exactly why I quit managing altogether. One can code or one can manage, but doing both means both are compromised.

</comment><comment><USER27> I swing back and forth. I go for months without touching the code, then I go for months where I stay in touch. It's easy to think a code base is decent when you stay close to it. Diving into a new code and unfamiliar code base allows me to see how new engineers will approach the code base, what's the onboarding/setup docs? Is it automated? install.sh or containeriazed? Are there tests? FAQ? user documentation, maintenance document? architectural documentations? If I can jump in the code fast and get moving, it's great. If not, I know the team is slacking and I figure out why and cover that area.

If pressed for time, then I might do the test/bugfixes cycle.

I code multiple times a week at home, so I'm not really pressed to program at work

</comment><comment><USER28> Good perspective. In my experience an engineering manager must be flexible. An engineering manager can really help the team excel by building productivity tools, prototyping new concepts documenting, or even fixing small bugs. With that, a manager should not let technical tasks get in the way of managerial duties.

I like the author's advice about not taking on work that may block your team. That is truly risky and can backfire. I've seen this firsthand -- But a manager absolutely must keep their head in the game technically. They need to be able to interface with other engineers and managers on a deeply technical level. They should have an awareness of their project's codebase that is best gained through being in it. An engineering manager without technical ability is a more like project manager.

In my org, I have seen the expectations of what a manager does shift quite a bit. With the addition of a tech lead role, it seems managers are silo'd into less technical, and less hands-on work. I feel that any sort of hard expectation or assigning percentages to management vs engineering time is ignoring the nuances of team dynamics, and individual personalities. A manager who can also effectively contribute code should do that. Likewise, an engineer who can boost team morale, mentor, help recruit/staff the team should. Take a look at the team dynamics and determine what mix works.

</comment><comment><USER29> "Work on Bug Fixes / Small Features"

That's terrible advice, in my view.

In your job you should always do what is the most useful and productive use of your time.

As a tech lead/manager your role is to manage/lead and your time is extremely valuable. In addition, your job as a manager is to allocate resources efficiently.

A small feature is a good task for a junior engineer. It helps them grow and their time costs less than yours.

Bug fixes should be the job of whoever knows the relevant part of the code best, which is unlikely to be you if you're a manager but even if it is you should aim to train and mentor others to acquire the technical expertise.

<comment><USER30> Having first hand knowledge about the state of the codebase is helpful to doing your job as a tech lead / manager. Doing bug fixes / small features is a productive way to gain and maintain this knowledge.

<comment><USER29> You can/should have visibility of the code base through design specs and code reviews.

There is absolutely no need to do a (potentially junior) engineer's job. It might be 'productive' but it's not the best use of your time or your role, and thus it is in fact a waste of time and money.

<comment><USER31> If you only have 20% of your time available to write code, then I would much rather you do not review code in which the person who wrote it had 90% or more of their time to write code. The review will be less thorough, correct, and timely than if someone else who regularly spends more time in the code.

These 'junior engineer' tasks are attractive for a manager who still wants to be in the code. They are non-critical and small. Perfect for someone with an unpredictable schedule. However, they also provide an opportunity for the manager to have a better, but still imperfect sense of the codebase and technology.

<comment><USER29> If you're a manager you don't have 20% of your time available to write code... If you want to write code then stay in a position where it is your role.

</comment></comment></comment></comment></comment><comment><USER32> This is the worst class of managers I have ever experiences: engineering managers with little dev experience. They rose quickly and became managers fairly early on in their career. They got excited by the opportunity, but then realised early on that they mostly attend meetings and write e-mails.

They miss coding, so they try and code between meetings, but without knowing our engineering practices, code reviews, agile methodology, ...

</comment><comment><USER33> I run an org of 20ish at a FANGish company. I have mgrs and a team of ICs reporting to me. Myself and my managers are on the oncall rotation along with ICs and we do light coding activities.

Pros- team morale, better tech decisions, skills stay up to date, oncall is quiet

Cons- more time consuming, develops bias against other mgrs that do not code

To each his own...

</comment><comment><USER34> As a new professor it seems I am supposed to act more like a manager and do less of the research/coding/data analysis myself. But I love to code! My goal is to keep a small project for myself that I work on when I don't have impending deadlines (basically never?).

</comment><comment><USER35> If you choose non critical bugs to work on, your managers will say _wtf is he working on that_ , and your next performance review will say "needs better judgement on priority of tasks" and you'll be let go in the next round.

</comment><comment><USER36> I guess am going down that path, am on the database side though. It terrifies me to be a people's manager, approving timesheets and crap.. I would love the mentoring part, but I'd rather skip and go straight to being the strategy guy.

</comment><comment><USER37> I like writing metrics-related code as an EM. It's valuable for me to be able to understand our data that's tracking our KRs and informing our KPIs. And I get to stay sharp on some frameworks we use here for surfacing metrics to the company.

</comment><comment><USER38> I find the bit about mentoring people outside your org interesting. I'm interested in mentorship myself. Does anyone know if there are actually rewarding mentorship programs on websites like meetup.com? Has anyone else done this?

<comment><USER39> Check with your local university or community college for mentoring opportunities.

For example, the University of California at Davis has a senior design class in their computer science program. You can submit a proposal for a project; if it's accepted you become the mentor and work with the students a couple hours a week over 4 to 5 months. I did this last year and found it extremely rewarding.

Edit: fixed typo

<comment><USER40> Did you have to pay money to do this?

<comment><USER39> No, it was more like just write a good proposal. There was a problem related to Swagger API specs that had been bugging me for a while, so I wrote it up and sent it in. I was delighted when it was accepted.

I'm planning to submit another project this year. Working with students is fun.

p.s., The class is ECS 193AB in case any folks living near Davis are interested.

</comment></comment></comment></comment><comment><USER41> What do we mean by manager in this situation? Is the first level "team leader" a people manager that engineers, or are we talking higher level managers?

</comment><comment><USER42> What is the difference between a tech lead and an engineering manager?

</comment><comment><USER43> As Engineering Manager I was doing Code reviews of my team;

</comment><comment><USER44> That would be great.

</comment><comment><USER45> > Work on Bug Fixes / Small Features

With this, I disagree for 2 reasons:

1) If your devs had to prove themselves technically via hiring process and you didn't, then your technical chops are potentially not up to scratch and devs have to tolerate inferior noise. Ditto with architecture input.

2) The easiest fix isn't always correct. Not having day to day knowledge of the code base means you're more likely to implement something substandard.</comment>


Tiny, cheap, and dangerous: Inside a fake iPhone charger - <AUTHOR> http://www.righto.com/2012/03/inside-cheap-phone-charger-and-why-you.html <comment><USER2> The larger Chinese-made chargers _generally_ don't have these issues (though a few apparently do).

Notice that this fake contains all or nearly all the components required to build a safe and working charger, including full safety isolation, fuse protection, and output regulation. The manufacturer's entirely capable of building one, they've just fatally compromised on safety in order to fit everything inside a tiny fake Apple shell.

(The blog post says it doesn't have a fuse, but generally instead of having a seperate fuse the input resistor on these power supplies is a special fusible resistor which is manufactured to also work as a fuse. Saves a few cents and some space at the cost of using a specialist component. Unfortunately it's impossible to tell it apart from a normal resistor just by looking.)

<comment><USER3> > _The larger Chinese-made chargers generally don 't have these issues (though > a few apparently do)._

Hardly a re-assurance now, is it?

<comment><USER4> Only electrocutes 5% of the time. What me worry?

</comment></comment></comment><comment><USER5> I have an friend's fairly expensive espresso machine in pieces in my living room due to electrical "problems." The (indeterminate far east supplier) blatantly omitted about half the input side circuitry, including the supply filtering. Numerous components identified on the PCB were never installed.

One lonely resistor protected the IC V_in for far longer than I would have imagined possible (years) before exploding.

As someone who is actively working to increase my electrical circuit-related design chops, intuiting how this thing continued to operate has been an interesting exercise.

</comment><comment><USER6> Previous: [https://news.ycombinator.com/item?id=3996171](https://news.ycombinator.com/item?id=3996171)

<comment><USER7> Yeah, the blog post was posted a year ago, but it's relevant again because of the accident in China.

<comment><USER8> Which accident? Have I missed news of a recent problem related to chargers?

<comment><USER9> Here's one link [http://www.chinadaily.com.cn/china/2013-07/16/content_167803...](http://www.chinadaily.com.cn/china/2013-07/16/content_16780313.htm)

<comment><USER10> Ever since clicking on that link, Google does not like me and is making me submit a captcha :-/

<comment><USER11> Switch to DuckDuckGo

</comment></comment></comment></comment></comment></comment><comment><USER12> This is how a real charger looks for comparison: [http://www.righto.com/2012/05/apple-iphone-charger- teardown-...](http://www.righto.com/2012/05/apple-iphone-charger-teardown- quality.html)

</comment><comment><USER13> This article is old (March 2012) and has been submitted at least twice prior. Here's the small discussion from the last time this was submitted to HN, over a year ago.

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

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

<comment><USER6> I mentioned that in a sibling comment and it was pointed out the article has an update at the top due to a related news event.

</comment></comment><comment><USER14> I bought what looked like a legit iPhone charger in Turkey a few weeks ago. However, if you touched the tip of the cord while it was plugged in, it would shock the hell out of you. I guess they skimped on a ground wire? I am not an electrical engineer. Would appreciate an explanation if anyone can speculate.

EDIT: I don't use this charger anymore, just to be clear.

<comment><USER15> Chargers typically aren't grounded. The AC and output sides of the charger are electrically isolated, but it seems like that isolation isn't working in your case. It's not uncommon for enough high-frequency current to leak through to be felt, but based on the description it sounds like you've got full AC leaking through. I strongly recommend you don't use this charger, since there's a real risk of electrocution in that case. I wrote the original article, so if you send me this charger I'll tear it down, figure out what's wrong, and post a writeup (my email is on the article page).

</comment></comment><comment><USER16> Anyone have any thoughts on this slim 45w charger? [http://www.amazon.com/GPK- Systems%C2%AE-Portable-Notebook-Sm...](http://www.amazon.com/GPK- Systems%C2%AE-Portable-Notebook-Smartphones/dp/B00AQLCMRM)

They seem to have good reviews across their range of products and have certification logos. However, I've been hesitant.

<comment><USER17> I'm guessing Amazon would be liable if they sold non-conforming devices, no? The charger described in the article clearly didn't respect the rules. Or maybe it's different in the US.

<comment><USER18> Amazon sells busted, bootleg products all the time, and the reviews can end up in the 1 star area. They don't pull them.

For a while literally all the XBox 360 wireless controller adapters on Amazon, for example, were Chinese knockoffs. For some reason Amazon stopped stocking the real ones, and let vendors put up knockoffs branded as the real thing, despite the reviews making it clear that they were fakes (and broke easily).

<comment><USER19> Amazon often has problems with listing knockoff products under the same SKU as the real thing. The Arduino project has had some serious problems with this in particular - for a while, if you bought an Arduino board, it was a roll of the dice whether you'd end up with a genuine one or a knockoff.

I bet the same thing was happening with the XBox controller adapters.

</comment></comment></comment></comment><comment><USER20> One of my favorite electronics tear down, he looks at two fake apple chargers. [http://www.youtube.com/watch?v=wi-b9k-0KfE](http://www.youtube.com/watch?v=wi-b9k-0KfE)

</comment><comment><USER21> I guess we shouldn't think twice when buying proprietary device, even if overpriced...

<comment><USER22> You should. This was common with PSU supplies back in the 90s - there were those so called Chinese firecrackers that just blew up and had a concrete brick to give the feeling of weight inside.

Then the market matured a bit and now you have gems like Seasonic and a stable manufacturers like Fortron that in the 2003-5 were with extreme performance for their price.

Don't pay the apple, samsung, MS and whomever tax if you can avoid it. It is unhealthy for the market and for the wallet. Just do a simple research that you are getting a kosher device.

<comment><USER23> Any tips on how someone who's not familiar with these things can work out what's legit and what's dangerous?

<comment><USER15> If you buy a charger for $2 on eBay and it's sent from China, it's almost guaranteed to be dangerous. If you buy a $19 charger from Apple, it's going to be as safe as you get. If you buy a cheaper charger from a store like Target, it'll be safe but probably worse power quality. More or less you get what you pay for. (No charger is 100% safe of course; Apple chargers have had recalls and occasional problems.)

I'm the author of the original post and I've torn apart and analyzed a lot of chargers if you want to see the differences between them: [http://www.righto.com/2012/10/a-dozen-usb-chargers-in-lab- ap...](http://www.righto.com/2012/10/a-dozen-usb-chargers-in-lab-apple- is.html)</comment></comment></comment></comment>


Explicit State Machines in React - <AUTHOR> https://www.afforded.space/state-machines-in-react/ <comment><USER2> This kind of app architecture looks so disgusting, can't be on board with this.

I posted this article earlier today, but it will probably get lost:

[https://blog.usejournal.com/reducing-the-pain-of- developing-...](https://blog.usejournal.com/reducing-the-pain-of-developing- apps-cd10b2e6a83c)

It does a good job of explaining why the developer friendliness of this architecture is an impediment.

Edit:

I just don't know even know what to say about how common this actions/reducer stuff is. Like really? We went from:

      fetch(url).then().error()

To this switch statement nonsense?

I'm at a loss for words at how little effort we're putting into reducing boilerplate, and making good usable apis.

<comment><AUTHOR> What do you do inside of the then and error blocks? _That_ is what this post (and state machines) are concerned with. Passing messages to a single entity (reducer in this case) that decides how to handle them, rather than spreading that logic across components, event handlers etc.

In terms of boilerplate, libraries like Xstate do a great job on that front. The goal here is to provide a from-the-ground-up overview of using explicit state machines.

<comment><USER2> A lot of my feedback is less about what the article is hoping to investigate, and more about the proliferation of these types of patterns in codebases.

We can still contain the logic on how to handle that request in a single function:

      fetch(url).then(updateState(whateverYouNeedToDo(response))

I don't think explicit state machine orchestration helps app architecture when we have been succinctly achieving the same thing with way less needlessness.

So I guess a lot of my frustration is that this stuff is literally in someone's bootstrapped todo app right now, or crud app. The normalization of articles like this in effect normalized code like this everywhere. I'd like to at least just yell back a little to reverse some of these trends that got adopted with little thought about trade offs.

In other words, don't even think about reaching for the explicit state machine scaffolding if all you really want to do is use immutable data and a fetch request. Ironically, the thing that needs to be explicitly declared is this warning.

<comment><AUTHOR> `whateverYouNeedToDo` needs to have knowledge of the application's state. Spreading application logic around event handlers is problematic. In sufficiently complex applications, we're better off simply 'passing messages' ([https://en.wikipedia.org/wiki/Message_passing](https://en.wikipedia.org/wiki/Message_passing)). Perhaps I'll start on a follow-up post which better outlines those benefits :)

<comment><USER2> Can give me an example?

Let's say I need to update state.tweets, what do I need to know here?

I know the fetch got handled, then I have my state and new data, what does message passing solve here? Or even better, if it solves _something_ , how do you justify this level of scaffolding that it warrants that trade off?

Edit:

I'll make one other suggestion. If you believe for sufficiently complex apps something like what you are suggesting makes sense, then provide that sufficiently complex example.

It's very hard for people to assess this stuff on a simple request/response handler. By this I mean it _actually_ gets used in the simplest possible use cases, where it has no business being used.

<comment><AUTHOR> Whether the user has switched from "Home" -> "Latest Tweets", whether the app has encountered an error since the request was made, whether the user has interacted with a previously loaded tweet, whether the user has quickly scrolled and another request is pending.

Thanks for the feedback. The benefits of modeling application logic with state machines are increasingly apparent as complexity grows. But that complexity makes for a dense blog post :)

<comment><USER2> Well, do write the dense blog post because it acts as something more substantial for surveyors who may not put more thought into it other than 'I guess this and stuff like Redux is how to do web apps now'. Usage of these patterns is not an insignificant decision without trade offs, and by no means right for every app. I can similarly make a case that some of the features you outlined for tweets could be done in a sensible intuitive way that doesn't introduce an explicit state machine.

I'll leave a good dense article on developer friendliness of some of these apis that you may want to address as well, since a larger symptom of the architecture you suggest is boilerplate:

[https://christianalfoni.com/articles/taking-immer-one- step-f...](https://christianalfoni.com/articles/taking-immer-one-step-further)

<comment><AUTHOR> Agreed! Always trade offs. Will give that a read. Thanks again.</comment></comment></comment></comment></comment></comment></comment></comment>


Acute exercise increases expression of telomere protective genes in heart tissue - <AUTHOR> https://www.ncbi.nlm.nih.gov/pubmed/28166612 <comment><USER2> It is hard for me to understand why a mouse study in a low-impact journal is at the top of HN.

The article does not appropriately adjust for multiple testing, and therefore none of its claims are well supported except the JNK2 decrease in post- exercise mice.

Full article is available at [http://onlinelibrary.wiley.com/store/10.1113/EP086189/asset/...](http://onlinelibrary.wiley.com/store/10.1113/EP086189/asset/eph12060.pdf?v=1&t=izh254dq&s=b9991ef92571e89cf3782940965238a12904dd93)

<comment><USER3> Looking at this article, and the one about the supposed use of falcons as anti-drone measures, makes me think about the whole "fake news" thing.

Something about how this is the quality of material we choose to promote among ourselves, the need for a critical eye when analyzing news, and how spreading fake stuff must be like shooting fish in a barrel.

Not the most joyful thoughts to start a morning!

<comment><USER4> For the record, I just read about the use of eagles (not falcons, though they are kept at falconries in France) in combating drones in a daily newsletter I highly respect. Here is the article they cite: [http://en.rfi.fr/wire/20170220-born-killers-french-army- groo...](http://en.rfi.fr/wire/20170220-born-killers-french-army-grooms- eagles-down- drones?utm_source=Sailthru&utm_medium=email&utm_campaign=New%20Campaign&utm_term=%2ASituation%20Report)

I guess I don't understand how at least the anti-drone eagles can be considered "fake news."

<comment><USER5> Do you honestly think a bird is a good solution to deal with what is, to the bird, a whirling blade flying death machine? I also saw people pushing the story about millions of wind powered devices to freeze the arctic, it's just impractical nonsense on the face of it.

<comment><USER6> I think you're using an older definition, wherein "fake news" means unworthy of attention. In recent weeks and months, "fake news" has been used by President Trump and others to mean factually incorrect.

Something being a bad idea or stupid or impractical doesn't make it factually incorrect, i.e., does not make it fake news under the new definition.

The article asserts several facts, among them:

\- birds of prey are often already kept near airports to scare birds away from the runway to reduce accidents during takeoff and landing.

\- the French air force has an experiment running with 4 eagles to train them to attack small drones, in addition to their normal scarebird duties.

\- the French air force thinks the experiment is promising enough to order a second group of 4 eagles.

If those facts are correct, it is not "fake news." It is a silly puff piece about something that is not important, because it will almost certainly never turn into anything beyond an experiment.

<comment><USER7> Simply, current definition "fake news" == propaganda

</comment></comment></comment></comment></comment></comment><comment><USER8> The pithy response is of course, "Exercise improves health. In other news, water is wet". But of course that's too simplistic ... this kind of research is awesome. Anything that can help us understand these mechanisms are one step closer to a literal fountain of youth.

<comment><USER9> > one step closer to a literal fountain of youth

I think you mean "Literally one step closer to a metaphorical fountain of youth." Or, in other words, the literal journey is literally the reward.

<comment><USER10> If, via this research (and heaps of handwaving), we can invent a water fountain that dispenses something that make you live longer. Then we have invented a literal fountain of youth.

<comment><USER11> Too complicated. Why not just hurl young people out of tubes on an ongoing basis? True, some passers-by will suffer fatal injuries from the impact of juvenile bodies, but literary fountains of youth have always had the possibility of unexpectedly killing off people who drink from them too often, so their unexpected deaths will be ironically satisfying. I can think of worse ways to go.

</comment></comment></comment></comment><comment><USER12> For anyone interested, a friendly plug for Dr Rhonda Patrick[1], who podcasts and speaks on nutrition, exercise, aging and telomeres in particular.

1\. [https://www.foundmyfitness.com/](https://www.foundmyfitness.com/)

<comment><USER13> Something about the design of that site makes me immediately suspicious and less likely to listen to anything she has to say.

<comment><USER14> I tend to stick to her YouTube channel, podcasts, and Twitter feed. You're right, her website is not doing her any favors. But she's a biologist, not a web developer. Hence, going directly to her content sources seems to be the best option.

<comment><USER13> I assumed someone else is handling her website stuff, so that just means they should try not to make it look like a scam site (subscribe popups on entry, and colorized "cancer" and other keywords). But maybe it's just targeted at different demographics, I don't know.

</comment></comment></comment></comment><comment><USER15> For those who cannot get beyond "mouse", here's an article and references about a human study:

"Lifestyle Changes Lengthen Telomeres" [http://www.drmirkin.com/public/ezine092913.html](http://www.drmirkin.com/public/ezine092913.html)

The study, by Dr. Dean Ornish, was published in "The Lancet Oncology" 17 September 2013 issue.

</comment><comment><USER16> How much exercise this should be in humans?

<comment><USER17> This study is looking at one specific mechanism by which exercise may be helpful in improving some aspect of your health. It's not especially useful to look at just this study though, as it doesn't actually link to any outcomes (the telomere protective expression may or may not actually reduce your risk for cardiovascular disease).

It's more useful to look at studies that have looked at actual outcomes (e.g. reducing the incidence of heart attack or stroke, etc). In those cases, the bulk of the evidence points to 30 minutes a day, 5 days a week of moderate exercise (e.g. a brisk walk or jog) being the best 'bang for your buck'. There are certainly gains to be made by going beyond that, but the curve falls off pretty sharply, and you can get almost all the (proven) benefits of exercise at that level.

EDIT: I would suggest this YouTube video from Healthcare Triage on the benefits of exercise that are supported by good research: [https://www.youtube.com/watch?v=SFBBjynBpSw](https://www.youtube.com/watch?v=SFBBjynBpSw)

<comment><USER18> Do you happen to know if the crucial thing here is "regular" excercise? As in, is it in important to spread out the excercise over the 5 days?

Would doing the 2h30 min excercise over say, 2 or 3 days per week, amount to the same benefit?

<comment><USER19> from what i understand (not being in any way a professional in any related field), its best to even split it up during the day. 15min early, 15min late is better than 30min in a block?

so i'd assume that short times more often is better

<comment><USER20> > _so i 'd assume that short times more often is better_

I wouldn't assume this. The logical end of this is to split your exercise into many tiny bursts throughout the day. But it's likely that _sustained_ output is an important part of exercising. The shorter your exercise, the less likely you are to get your heart into an elevated range, the less likely you are to cause an oxygen-depleted state (which encourages vascular growth), the less likely you are to use a significant portion of your free glucose (which is important for insulin sensitivity), etc.

I don't know where the threshold is, but it seems like a bad idea to assume that shorter, more often is better. It likewise seems like a bad idea to assume that longer blocks are better (or just as good). Any exercise is far better than none, but there is a lot of support for ~30 minutes ~daily being extremely valuable. Absent evidence, I'd be hesitant to assume that some other arbitrary division of exercise would yield the same results.

<comment><USER21> > the less likely you are to cause an oxygen-depleted state

I don't know if this is a safe assumption either. What makes you think it would take more than a few minutes of acute exercise to reach an oxygen depleted state?

<comment><USER20> Basic physics. Assuming you are generally healthy, your body is not _usually_ in an oxygen-depleted state. Therefore it will take some amount of time in a state of increased oxygen use to cause oxygen depletion. Therefore, "the shorter your exercise, ... the less likely you are to cause an oxygen-depleted state".

Depending on your fitness level and exercise level, it will take more or less time to put you into this state. An overweight, sedentary person sprinting will be there pretty much instantly. A marathon runner walking briskly won't get there in any amount of time. But all things being equal, more time exercising will be more likely to put you into an oxygen-depleted state (and glucose depleted state, and elevated heart rate).

<comment><USER21> For endurance athletes like your marathon runner, this is certainly the case. Strength and power athletes can certainly expend far more energy in a shorter time than someone who is less fit. It's a bit of a paradox where the better shape you are in, the sooner you can tire yourself out. From everything I've read, it certainly seems possible to reach oxygen depletion in a very short period of time.

[https://mobile.nytimes.com/blogs/well/2016/04/27/1-minute- of...](https://mobile.nytimes.com/blogs/well/2016/04/27/1-minute-of-all-out- exercise-may-equal-45-minutes-of-moderate-exertion/?referer=)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> I've assumed for a very long time that the purpose of telomeres was to prevent cancer mutations from killing a complex organism, since the resulting growth would be limited to X generations where X is the number of telomeres on the mutated strand of DNA, and then die without those cells being able to divide again.

So while I believe the study will likely hold up; I do wonder why exercise adds telomeres. One answer is that exercise reduces cancer risk (it will get you to bed on time, mostly) so the body optimistically adds teleomeres. Alternatively, and perhaps more likely, exercise may trigger more cell division (for purposes of repair, all exercise causes some damage, to collagen if nothing else) so the extra telomeres are added as compensation in order to return to status quo cap on allowed cell divisions; maintaining the preventative but not actually extending it.

</comment><comment><USER23> Out of pure curiosity, what does this mean in english?

<comment><USER14> Exercise is good for you.

More specifically, intense exercise seems to protect the length of the heart's telomeres, which are the ends of your DNA strands and shorten as you get older. They are linked to the effects of aging, so delaying their shortening would seem to indicate delaying the effects of aging.

<comment><USER24> What does "acute exercise" mean?

</comment></comment></comment><comment><USER25> How would we check these results in humans? Can we safely biopsy someone's heart?

<comment><USER26> biopsies of the heart can be done, but only for compelling reasons. it carries non-trivial risk to the individual.

untilHellbanned described the better way -- ideally, there would be some sort of biomarker in the blood that serves as a proxy for the level in the heart. But how do you find it and validate it? It's challenging (at best...)

<comment><USER27> I would think for research purposes autopsies would give you better data than biopsies, and without any risk.

</comment></comment></comment><comment><USER28> TLDR; exercise

</comment><comment><USER29> In other news, smoking is bad for your lungs!</comment>


Thank You Lennart - <AUTHOR> https://glyph.twistedmatrix.com/2014/10/thanks-lennart.html <comment><USER2> Meh.

There was a reason he got so much vitriol: he's a terrible and manipulative person who is using political methods to push an anti-POSIX agenda. He's a Weev-level troll for an audience too stupid to realize the damage he's doing. He over-exaggerates a joke on IRC into a perceived attempt/threat on his life, and uses that as a springboard to insult Linus Torvalds for doing far more benign things than he regularly commits, whilst playing the victim card to the fullest.

I'll join the author in thanking lennart. Thank you for holding the Linux ecosystem back by politically forcing your bad monolithic software on us. Thank you for showing that not only Microsoft can implement "embrace/extend/extinguish" to ruin Linux. Thank you for showing the world how to use an open source company like red hat to muscle your changes into other distributions. Thank you for reinventing JACK's wheel. Thank you for introducing a new paper cut for every one Mark Shuttleworth endeavored to fix. Thank you for saying that people that disagree with you must obviously "hate the disabled" because they don't agree with your decisions.

And most importantly, thank you for showing how gullible and vulnerable the open source movement is. Not even Microsoft hurt Linux as much as you have, and this is with SCO vs. IBM in mind.

The next time I see him, I plan on telling him this verbatim.

<comment><AUTHOR> I agree with the OP and with jerven's reply. Just one question: What makes POSIX, and Unix in general, so sacred that an anti-POSIX agenda is inherently a terrible thing, worth being opposed with such vitriol? Unix is just one way of many to put together an operating system. If the major GNU/Linux developers, inspired by Mr. Poettering, want to try a different direction, they're entitled to do that.

<comment><USER2> It appears you may be new to this whole "Unix" thing. What made unices popular was their ubiquitousness. If you had a BSD machine on the same network as a Linux or SunOS machine, they can communicate using standard protocols. Further, the applications themselves were portable between POSIX implementations.

The Unix Way is to have small programs that do one thing extremely well; when an application (with the exception of emacs) starts emulating Zawinski's Law, they're usually broken up into smaller pieces. I do not want one app that handles cd, ls, pwd, rm, mv, etc. I suspect that if Poettering/Sievers released an app (let's call it "fileD") that did exactly that, the Unix community would gather the torches and pitchforks to go put an end to the nonsense.

Kinda like they're doing right now with systemd.

A Unix that does not implement or respect POSIX is not Unix. And if the major GNU/Linux developers wanted to try a different direction, they can. But they don't. The majority of developers want to keep Linux this way. two engineers from Red Hat want it this way, and politics are driving it's adoption rather than technical merit.

<comment><USER3> > Further, the applications themselves were portable between POSIX > implementations.

It appears you may be new to this whole "Unix" thing. Application source portability was never absolute, not by a long shot, back when Sun and SGI and HP were still relevant to what Unix was. They all had value-add APIs, little different ways of doing things which were deliberately different from everyone else's to encourage lock-in. And even disregarding that, the BSD/SysV split was even stronger then than it is now, with heterodox APIs like STREAMS still in use.

Linux and the Open Source BSDs are still different, but the standards are better-followed and the auto-configuration tools are better.

<comment><USER2> > It appears you may be new to this whole "Unix" thing.

I understand that you're doing this out of malice, and are using "reflection" in order to make yourself feel superior, and to take me down a peg, but I do regret using that sentence in the GP. The rest of the post was completely accurate, and that sentence diminished it.

However, I'll have to disagree with the rest of your reply; The BSD/SysV split, while large, is fairly comparable to what's going on today with systemd. Poettering has made his contempt for *BSD very clear multiple times, and is actively trying to extinguish compatibility with it.

GNOME needs massive work to play nice with any BSD now, thanks to Lennart. Porting between SunOS/IRIX/HP-UX was far less work than GNOME now requires.</comment></comment></comment></comment></comment>


A Visual Guide to Evolution Strategies - <AUTHOR> http://blog.otoro.net/2017/10/29/visual-evolution-strategies/ <comment><USER2> "Wall clock comparison. Instead of looking at the raw number of states seen, one can argue that the most important metric to look at is the wall clock time: how long (in number of seconds) does it take to solve a given problem? This quantity ultimately dictates the achievable speed of iteration for a researcher. Since ES requires negligible communication between workers, we were able to solve one of the hardest MuJoCo tasks (a 3D humanoid) using 1,440 CPUs across 80 machines in only 10 minutes. As a comparison, in a typical setting 32 A3C workers on one machine would solve this task in about 10 hours." [https://blog.openai.com/evolution- strategies/](https://blog.openai.com/evolution-strategies/)

</comment><comment><USER3> I would _love_ to see this with a more complicated search space. The two examples are too easy to climb.

Would be really interesting to see how the different algorithms travel through a landscape where it is hard to find the optimum.

And to make it perfect: Put information about the performance below each visualization.

<comment><USER4> Near the bottom he does show the results of running it on 100-D Rastrigin (and mnist before that) with stats and plots. Or do you mean something more complex even than that?

<comment><USER3> Well, the point of the guide is the nice 2-D visualization. Which he cannot do for the 100-D problem of course. It would be nice to make the same guide but with a harder 2-D landscape.

</comment></comment></comment><comment><AUTHOR> The next article in the series, Evolving Stable Strategies, is also up.

[http://blog.otoro.net/2017/11/12/evolving-stable- strategies/](http://blog.otoro.net/2017/11/12/evolving-stable-strategies/)

</comment><comment><USER5> For me the biggest advantage is that ES often lends itself better to multi objective optimization. Discussed here: [https://news.ycombinator.com/item?id=15584858](https://news.ycombinator.com/item?id=15584858)

</comment><comment><USER6> 80s are so in right now, first neural networks, now genetic algorithms :P

<comment><USER7> what next... a discovery of the limitations of machine learning?

<comment><USER8> I'm scared by what the Japanese are doing with Prolog…

<comment><USER7> Actually the advances in logic programming are quite compelling; answer set programming is pretty cool!

I'm not sure why it's having such a small impact though - perhaps the shear number of low cost programmers available means that no one has to use it. Although I would have thought that high cost programmers equipped with tools like these could better justify their pay.

</comment></comment></comment></comment><comment><USER9> Without Javascript the mathematical expressions are not displayed. This makes some parts of the text incomprehensible.

<comment><USER10> Yeah, but if you just casually don't use Javascript on the web, you're not worth catering to.

<comment><USER9> [https://en.wikipedia.org/wiki/Progressive_enhancement](https://en.wikipedia.org/wiki/Progressive_enhancement)

<comment><USER10> Yes, I know what progressive enhancement is, my point is that it's not worth the effort of starting from literally just html and CSS to cater for the people so unwilling to work with you that they don't even have the second most basic web tooling enabled.

And what kind of cost-benefit analysis is _ever_ going to tell you that it's worth catering for the less than 0.5% of people who turn off JavaScript?

<comment><USER9> "As long as you're fine with the site completely failing because the browser is too old, or too new, or the user's bandwidth is too constrained, or the server hiccups, or a firewall's security policy blocks it, or a dependency goes sideways, or you accidentally drop a semicolon somewhere, then sure," says consultant and author Eric Meyer, "it's OK. What you build won't be a part of the web continuum, and it will be needlessly fragile, but that's a choice you can make."

[http://www.creativebloq.com/features/is-it-okay-to-build- sit...](http://www.creativebloq.com/features/is-it-okay-to-build-sites-that- rely-on-javascript)

</comment></comment></comment></comment></comment><comment><USER11> I like it :P</comment>


A private military company is now providing security in Ferguson - <AUTHOR> http://www.theverge.com/2014/8/20/6050937/private-military-in-ferguson

<comment><USER2> The original title is better _A private military company is now providing security in Ferguson, for just one person_.

I don't feel like I learn much of anything when an individual I know nothing about does something like hire additional security.

</comment><comment><USER3> Civilization is so fragile.</comment>


Ask HN: Does the CEO need to set the strategy or can a co-founder do that? - <AUTHOR> I'm CEO of a startup and at the moment, one of my co-founders is owning product strategy. He is responsible for defining what the company will be doing for the next few months to accomplish our goals.
This is starting to get touchy because he's starting to feel like he is doing the CEO work. Because I'm the only engineer, I'm also in effect CTO, which leaves me less time to read/focus on the strategy and more time for him to do so. I still manage fundraising, legal, taxes, etc.
Is this normal/healthy, or will this inevitably lead to issues? Does anyone have a similar split? <comment><USER2> Stop thinking of who is CEO, who is CTO, which one should do what kind work. Startup founders should think about what makes your company survive.

If your customers/investor come to you because of your R&D, R&D head should control the company, earn most, and all other work should be done by other co- founders.

Otherwise, if they come to you because of your product strategy, then you should let that guy control the company, it's good for you at the end.

If none of you know what is the core competitiveness of your startup, you all should more concentrate on the product/service/marketing per se. Who take control is not important and you all will learn a lot.

</comment><comment><USER3> The CEO has the biggest vote. CEO is the only role in which specific competencies can be exercised, and non-leadership gaps can be hired for. Strength of the CEO determines the size and number of gaps. Yes, it's possible for the CEO to delegate product decisions in support of specific goals, but it's the CEO who ultimately sets the company goals and fires the product person if needed.

Here's an interesting thought exercise: if one of you were suddenly unavailable (hit by a bus, won the lottery, etc) and the remaining person had to hire contractors to fill in that role, would the company continue? Is it the same company with the same vision? The CEO is the chief storyteller... the keeper of The Lore. In a very small company that does not yet have its own self-sustaining culture, replacing the head will result in a company which is something "other".

More practically, I'd advise you to think carefully about what _you personally_ are trying to achieve. Want to remain in the weeds? You may be much happier transitioning to a more technically-focused role and handing off the strategy bits. Are you high-control and want to drive the ship, even if it means stepping away from the tech? Then execute like crazy in the big chair and truly own your role, but understand that this probably means recruiting technical / technical leadership help sooner rather than later.

</comment><comment><USER4> CEO is the one with all the information. The one with the most information and the most rationality should make decisions.

That doesn't necessarily mean creating a strategy, but sometimes just approving one.

And like in your case, often a startup CEO gets burdened with technical, funding, sales, finance, legal, and so on. I personally resolved never to be a CEO & CTO again, because you're effectively a solo founder for a good portion of time - the non-CEO cofounder can't do a lot of things and development is often the bottleneck.

</comment><comment><USER5> Do his strategic decisions appear to be good and in line with what you'd be doing to do?

If so, stop worrying. If not, your problem isn't to do with job title and responsibility mismatch.

</comment><comment><USER6> who ever is talking with customers should be working out the product features. I would argue there needs to be agreement about all major decisions, though. agree to agree. if you can't agree go with what that customer says and go from there. and/or test your assumptions.

</comment><comment><USER7> You're the CTO in all but name.</comment>


Ask HN: How do you scale a community while retaining quality? - <AUTHOR>

Let's say you have a small size site with good users.  You want to grow the site but not at the expense in the quality of users.
You want to add features which will make the site more interesting (like Reddit's article voting system) but you definitely do not want the site to turn into another Reddit.
You also don't want to do stuff like create a membership committee and a bunch of red tape to join the site.
What options are out there? <comment><USER2> It really depends on the service, but basically comes down to promoting desired behavior (in this case quality content, be it posts or videos or whatever). Find some way by which quality can be measured (e.g. upvotes or moderation) and award users accordingly (e.g. giving more permissions based on upvotes/reputation, or hand-pick featured content). Optionally, discourage low quality content as well.

</comment><comment><USER3> Have a browse through Meatball wiki. Although it's aimed at wiki style communities it has relevance for many others.

(<http://meatballwiki.org/wiki/>)

You need to force good behaviour. Avoid "vested contributors". Meta is usually death; have some kind of separate channel for meta nonsense.</comment>


Comparing the financial performance of Netflix vs. HBO - <AUTHOR> http://iveybusinessreview.ca/blogs/lbolukhba2010/2014/03/07/comparing-the-financial-performance-of-netflix-v-hbo/

<comment><USER2> Those "almost costless revenue streams" that HBO has abroad will be insta- killed if Netflix manages to enter those markets.

We here in Germany (and much of Europe) are stuck in a world where Television and DVD/Bluray are the only viable legal options for series and shows. This is of course absolutely not what the consumers want, but a consequence of the byzantine licensing structure that exists over here.

There are two ways in which this can flip almost instantly:

1\. The EU decides to end the bullshit and bans regionally limited licensing deals, thus making the market much more accessible for all those VoD companies that keep trying to break through.

2\. Netflix or some other major player muscles their way in.

If one of those two happens, then the bottom will fall out of the foreign revenues of HBO.

<comment><USER3> You do know Netflix buys region-exclusive content rights? This would hurt them as well.

Furthermore, HBO only sells its content overseas. There will always be a buyer - indeed there are more than ever. They don't really HBO Belgium to succeed. They just need someone to buy their content.</comment></comment>


How To Choose Programming Languages For Team Projects (Hint: Avoid Scala) - <AUTHOR> http://blog.captainrecruiter.com/2010/12/how-to-choose-programming-languages-for.html

<comment><USER2> Wow, an entire article about the costs of choosing an obscure language—which are real enough—but nothing about the benefits. I think everybody here understands that Java and C# are popular, and that this means you'll have an easier time finding libraries and warm bodies.

Here are some other questions the recruiter should have asked:

1\. Can you develop your application less time using Closure or Scala than Java? How much less time? Can you iterate faster and try out more ideas before you run out of money?

2\. How easy it to recruit _good_ programmers who know Java? In my experience, less than 5% of people who apply for programming jobs know how to reverse a singly-linked list. In a startup, you care about the ease of recruiting 10x programmers, not the ease of recruiting warm bodies.

In short, the article explores half the problem. Without exploring the other half, there's no way to decide which companies should follow this advice, and which should contemptuously ignore it.

<comment><USER3> Manager-types are more risk-averse than they are opportunity seeking.

Grokking that goes a long way towards understanding this kind of blind decision making.

<comment><USER2> _Manager-types are more risk-averse than they are opportunity seeking._

But is this an appropriate strategy for a startup? As Paul Graham points out, the average startup fails, so you don't want merely average performance. If you're not prepared to manage risky tradeoffs, you may not be prepared to manage a startup.

<comment><USER3> >But is this an appropriate strategy for a startup?

No. A startup should just use whatever the tech co-founder is going to work fastest in.

Hiring strategies shouldn't even be a consideration for a startup.

</comment></comment></comment></comment><comment><USER4> I thought there was something odd about the article, then I found the explanation:

"I'm Just A Recruiter With An Opinion"

Sorry, in my experience the opinions of recruiters on anything like choice of programming languages is probably worse than useless.

<comment><USER5> So why not talk about what he's wrong about, instead of writing ad hominem attacks on him?

<comment><USER4> Largely because it regards developers as a commodity that can be summarized with a few keywords - which is something I have always hated.

Incidentally, I did co-found a start-up in '94 where we chose Java as the platform because we wanted to to do shrink-wrapped server side applications. Java was probably a lot less popular then than Scala is now and that choice turned out to be a _huge_ advantage for us technically. I don't think any of first round of developers we hired had any real Java experience - it really wasn't a problem.

</comment></comment></comment><comment><USER6> Smart people can move between languages easily. It's concepts, understanding of problems and patterns that are important.

I will continue to choose languages that I enjoy and will continue to recruit people who also enjoy the challenge of learning new things.

Sure, a new hire may not have any Scala/Ruby/Erlang experience, but if they understand about source control (you'd be surprised!), testing, enterprise patterns and how to solve a God-damned problem, that's all that is important.

<comment><USER5> "Smart people can move between languages easily. It's concepts, understanding of problems and patterns that are important."

Important to what?

When starting a company, I think it's perfectly reasonable to worry about how easy it is to find people who know how to use your tools already. Sure, you can always train new people, _but it takes time_. In a new company, time is usually against you.

Not to mention, you want a good ecosystem for your tools, so you can leverage other people's work.

<comment><USER6> Important to being a great developer. Languages and tools are interchangeable. It's the basics - the ability to problem solve, learn and adapt to new environments that are truly important and timeless.

Sure, being exposed to a new set of languages and tools can have some start-up penalty. But if it takes someone more than a few weeks (< 3) to be good at Scala, Ruby, Python, etc then there is something wrong. Running through a complete tutorial and solving real problems on a real codebase over a couple of weeks should be more than enough time to become proficient with a specific language if you already have the skills of being able to problem-solve.

Don't confuse choice in your ecosystem of tools for quality. Just because there are tens of thousands of libraries for Java and .Net doesn't mean they are all good or that you can automatically choose the good ones.

The beauty of a more recently popular languages is that smart people tend to be attracted to them and, in my experience, they tend to create better quality libraries and tools, even though they are less of them.

</comment></comment></comment><comment><USER7> What no Perl or Python?

Below are the figures I get (at this point in time) for the top two sets of figures provided in the post:

indeed.com:

        36,337  Perl    (#3)
        18,470  Python  (#5)

linkedin.com:

        126,992 Perl    (#4)
         68,630 Python  (#5)

</comment><comment><USER8> That looks like a sure fire way to make sure you only hire mediocre programmers.

</comment><comment><USER9> __1) __I think people really overestimate the effort required to learn a new language. When I've changed projects in the past, learning the language was much easier than learning the codebase and project/business requirements.

If I was assembling a team of Java programmers today, I'd prefer to hire an excellent Python developer than an average Java developer * . A great programmer can learn a language faster than an average programmer can become a great programmer. The great programmer could be reasonably productive with Java after two weeks, but an average programmer is unlikely to improve their problem solving skills, or their ability to cleanly structure large programs after the same period of time.

* Feel free to replace 'Java' and 'Python' with any two languages within the same paradigm. I don't mean to pick on Java as a language.

 __2) __In the article he's ignoring many advantages that smaller languages have going for them:

\- Much, much higher signal-to-noise ratio when hiring: The people who currently know Scala or Haskell learnt it because they love to program – they sure as hell didn't learn them to land a job. You can't say the same about Java, C# or PHP.

\- You may make your company more attractive to the best developers: A company advertising for work in Java sounds very average (and a place to work for pointy-haired bosses). It will have to work a lot harder to stand out from the crowd. A company sounds interesting if it uses interesting languages.

\- Great programmers will usually prefer to work with languages they are passionate about.

\- Great programmers like working with other great programmers. I can assume I'm working with better programmers when joining a Scala team than a Java team. When hiring, you have to work harder to convince me you're good if you are a Java team.

\- If you only hire great programmers, you can have smaller teams: ie, you don't actually need to hire as many programmers.

\- And, of course, it ignores whether these languages may be more productive to work in.

<comment><USER10> I agree with your first point, with one caveat: Only good developers try to learn new languages enough to get good at it.

At the price of arrogance, the "Average" developer in the "Average" company is pretty bad at developing. The experience I've had is that learning things is usually a good indicator of the love for doing things well.

The people who write crap code tend to also be the ones who don't even want to learn new languages, let along et good at doing so.

</comment></comment><comment><USER11> Those ITA guys who based much of their infrastructure on an "esoteric" language clearly didn't know what they were doing.

<comment><USER12> ITA, wasn't it the company that got a Lisp project cancelled from Air Canada because the project was going nowhere after 4 years?

<comment><USER13> Given the timing of Air Canada's withdrawal from the project and the Great Recession, which has played merry havoc with air travel, I don't think that's what happened.

Especially since ITA is still working on RES. Which is only "1/3" Common Lisp (web based front end is Java centric, back end is Oracle RAC, stateless middleware is mostly but not entirely Lisp).

</comment></comment></comment><comment><USER10> This argument isn't even internally consistent, let along based on good predicates.

He states that the better languages are the ones being learned. Then shows that Scala is the most popular language to learn ATM.

He then states that you should use a language with lots of popularity, which he also shows to be Scala.

Then dismisses it because there aren't many other companies using it, or developers who know it. Well, no shit: They're all busy using it and starting their own companies that aren't yet big enough to hire!

I have a bias that states that people who use github, hackernews and learn new languages are better developers in general because they give a shit about their profession. By this articles hypothesis, those people are worth exactly the same as any other developer, when we KNOW that a good developer is a MUCH better developer then an average one.

</comment><comment><USER14> I'm surprised C/C++ isn't in the list I get the following result:

148,296 jobs (#1)

<comment><USER7> _Don't want the facts to ruin a good story!_ :)

</comment></comment><comment><USER15> Disappointing link. What I would be really curious about is an assessment of (some of) Scala's features and their effect on code readability, reuse, etc.

I don't know nearly enough Scala myself to have a proper opinion on this. From trying out Scala, I remember some features that seem highly dubious to me from a maintainability/readability point of view. In particular implicits and right-binding operators ending in ':' did seem to be asking for trouble, to a lesser degree the sometimes overly punctuation-based syntax ("\:" is the method name of fold left...).

</comment><comment><USER16> For an article that bitches about Scala too much, the recruiter clearly overlooked another poster child of Scala - Twitter! While the general premise is well intentional, but really, what you need the tool for makes more sense. Sure, FourSquare and Twitter use Scala - but the rest of world's backend needs aren't that special cases.

I hope the op recognizes that organizations are inherently islands and sometimes the smaller more productive ones tend to be little paradises of productivity with no ferry service. Happy swimming there :-)

</comment><comment><USER17> He has it backwards. Choose the developers because they are good, then let them choose the programming languages.

<comment><USER18> The problem with that approach is you'll end up with a program written in a dozen different languages and no single person can understand it.

I once worked at place that had a, relatively small, code base that contained more or less equal parts tcl, C, Lisp, Visual Basic, C++, Perl and probably something I'm forgetting due to the fact that the programmers got to choose their languages without any sort of supervision. It was no fun at all for anyone to work with.

<comment><USER12> I once worked at a place that had a code base that contained more or less parts in Ruby, Perl, Java and PHP. It was not fun at all to keep enough knowledge in the company over the years to maintain this nightmare.

</comment></comment></comment><comment><USER19> Those who try to hire Haskell devs (and write about it) seem to have no trouble finding experienced people. In fact, it seems like there is almost a "glut".</comment>


The Ethereum Computer – Securing Your Identity and Your IoT with the Blockchain - <AUTHOR> https://blog.slock.it/we-re-building-the-ethereum-computer-9133953c9f02#.hvb6h73ja <comment><USER2> Slock.it Team here, feel free to ask questions and I'll do my best in answering.</comment>


Resumable OpenZFS send/receive - <AUTHOR> http://blog.delphix.com/matt/2015/03/25/resumable-zfs-sendreceive/

<comment><USER2> Awesome! When the great split first occurred, I was really concerned that the Illumos path would die on the vine. Especially after Nexenta started hiring up everyone they could and not really seeming to attempt to give code back. Having been a huge Sun fan when they finally opened Solaris, and then dreading the Oracle acquisition, it's awesome to see major features continuing to make it back into the open source version of ZFS.

</comment><comment><USER3> This is great news for people like rsync.net, anyone using zetaback, or people using znapzend. I suspect cloud storage via ZFS will see the most benefit, as they'll be sending full datasets over lower bandwidth links. The zfs backup solutions will have less benefit (except with restores) as most backups end up being incremental.

</comment><comment><USER4> IS this going to be integrated into ZoL?

<comment><USER5> ZoL is OpenZFS, so you'd expect a future release of ZoL to include this feature.</comment></comment>


Ask HN: Anyone wiling to help a fellow dev? - <AUTHOR>

The gist:
1. I'm a seasoned dev by trade supporting my family by coding all the time.
2. I work for others but finally now want to make something that is my own and may help give me some more freedom.
3. I've been approached by others to fix a certain problem, so I built a simple rails app to solve this problem.
4. The app is 95% done - I just have a couple features left before launching.
5. I could really use some help teaming up with someone on one of my last features.
Looking for kindness and someone I can trust to access my source code.  I've spent a considerable amount of time on this and don't want to screw it up as free time for me is hard to come by.
Lastly, I can't pay yet, looking for some pro bono help.  Good news is I don't expect to take up a lot of your time - maybe just some peer review and help figuring out my last feature.
The app is in Rails 3 - but this feature involves file uploading maybe it can be in a different language.
If interested contact me via northband_at_gmail_dot_com <comment><AUTHOR> I think its freaking awesome that I got some response. I feel like Tarzan who just shouted out into the jungle and got fellow devs to team up and help me! Kudos HN!

</comment><comment><USER2> Email sent!</comment>


A New Step from BDD – Crius - <AUTHOR> https://medium.com/@unadlib/a-new-step-from-bdd-crius-77405fe88ae5 <comment><AUTHOR> Crius is a Step-based BDD build tool. It is the primary expression of the DSLs with JSX, all behavior and expected results can be defined as Step, and the declarative Step design makes it easy to quickly build test logic.</comment>


Course: Computational Thinking using Julia, with examples modelling Covid-19 - open-source-ux https://github.com/mitmath/6S083 <comment><AUTHOR> Enjoying the lectures and notebooks. Highly recommended.</comment>


Icing PayPal: How We Did It - <AUTHOR> http://blog.wepay.com/2010/10/icing-paypal-how-we-did-it/

<comment><USER3> What I've learned from this: Calculated publicity stunts done by massive corporations are no less endearing to me than calculated publicity stunts done by small y-combinator startups.

I look at this publicity stunt with the same yawn+rolleyes as when Richard Branson takes his clothes off or Donald Trump insults Rosie O'Donnel.

It's good business, I guess, but it's ham-handed and doesn't move me.

<comment><USER4> My guess is that if you'd already heard of WePay before yesterday, you weren't the target audience for this publicity stunt.

<comment><USER3> I totally get that it was successful stunt that got them attention. Any attention is good attention and all that. That wasn't my point though.

</comment></comment></comment><comment><USER5> The idea is excellent, but the execution could have been better. I don't want a financial company I use to have a plan revolving around running away from a security guard. Had they done some social engineering or even obtained some sort of permit through their lawyers to leave the ice there, I would have been much more impressed. After all, who can say no to an up and coming ice sculptor wanting to display his work outside a hotel for a day? Still though, great idea.

<comment><USER6> we're a startup with a lot on our plate and this was a fun side project. we didn't spend weeks planning this, just a night.

<comment><USER5> I know the criticism is unfair, which is why I tried to couch it. :)

</comment></comment></comment><comment><USER7> This approach to business feels a bit amateur and lacking in class to me. I realise there has been a fair amount of publicity after this episode, and maybe I am 'old school' but it just doesn't feel right.

<comment><USER8> P. T. Barnum, now he was old school! He never shied away from using ridiculous stunts like this to get attention. He would write newspapers under pseudonyms railing at his own products to get noticed. He once hired a begger to place 4 bricks at various points on the sidewalk outside his famous museum. The begger would take a 5th brick and walk around on a circuit, replacing each brick with the brick in his hand. Every hour, he would brandish a ticket and walk through all the galleries of the museum. Soon, he'd generated enough curiosity that people were buying tickets to the museum just to follow him around. Some were even staying inside, captivated by what they found on display.

Foolish stunts are as old school as it gets.

<comment><USER9> "The Fabulous Showman" bio of P.T. Barnum. Essential business reading.

</comment></comment></comment><comment><USER10> I want to understand why this is good marketing and who has moved from Paypal to Wepay. The services are very different, Wepay seems to cater to a tiny percentage of American Paypal users, it's like Hackernews competing with Reddit. Can anyone clarify if this is a legitimate "move to Wepay from paypal!" thing or if it's just a way to get attention, not necessarily customers?

<comment><USER11> i think this was more about getting press and making people aware of wepay's existence. most people who fit into their niche are likely not aware of them.

<comment><USER12> Please, correct me if I'm wrong but I don't think their niche overlaps too much with paypal customers. So why would they market themselves as a direct competitor to paypal? Why would they, given this premise, advertise to paypal customers at all?

If you read the whole story you will get the impression they are paypal competitors - that is, unless you visit their website and read comments here. You will find out they are nothing like paypal and they won't replace it.

They're riding paypal disappointment tide _cough_ diaspora _cough_ yet they don't offer viable replacement.

There's been a lot of negative opinions about paypal coming from this very community but, in my opinion, if they position themselves as paypal competitor a lot of people will be disappointed in their offering right now.

Do you think it's a good way to market themselves? Or should they focus on their core audience via other channels? Or maybe paypal customers are indeed wepay's customers in the making?

<comment><USER11> they are not a direct competitor. their offering is not equal to paypal's. they only do a few things, but try to do them well.

the services they provide are similar to some things that people are doing with paypal.

</comment></comment></comment></comment><comment><USER13> Man I would love to use WePay, but from their website they don't seem to do the same thing as PayPal at all. Can you send any WePay user money via email?

<comment><USER14> WePay lets you collect money (people can pay you with credit card or bank account) and then you can send money that you've collected to whoever you want. So you could, if you wanted, put money in your group and then send it easily to whoever.

<comment><USER15> So... "No."

</comment></comment></comment><comment><USER16> I hate PayPal with a passion. We've been using it for 3 years as our online payment processing and every 3 months or so they do something that causes us hassle like an auto refund for no valid reason. I've considered changing - <USER2> then just think other payment processors are probably just as bad? Or are there really good guys out there?

<comment><USER17> Having used PayPal to process thousands of transactions for almost 8 years now, I've never once seen PayPal issue a refund for "no valid reason". You will always receive an email outlining why the funds are being placed on hold pending an investigation. You will also have the opportunity to respond to that investigation by providing whatever correspondence, log files, etc. you feel are pertinent to the investigation.

I Have also worked with many other payment providers (2checkout, authorize.net, AlertPay, WorldPay, FastSpring) and they all do the same thing.

</comment></comment><comment><USER18> Does WePay process payments themselves, or do they use a third party payment processor?

</comment><comment><USER19> Can you use WePay to automatically charge for premium usage of a web app (one time and/or subscription)?

</comment><comment><USER20> I wonder what the charge would have been if the police got involved. Littering?

<comment><USER21> Perhaps they would be charged with disturbing the peace or disorderly conduct. Most localities have catch-all ordinances that police can use in these situations.

</comment></comment><comment><USER22> What image did the one dollar bills form inside of the ice? I feel like there is something there I'm missing.

<comment><USER22> I wasn't being sarcastic it looked like maybe there was a 2nd joke in the arrangement of the fives vs the ones. Oh well.</comment></comment>


Show HN: Assemble a vetted offshore dev team in a few clicks - <AUTHOR> https://www.producthunt.com/posts/youteam-2-0 <comment><USER2> Flagged because linking to producthunt, rather than your actual site, is a spammy behaviour.

<comment><AUTHOR> My mistake. Sorry about that: din't know this is against the rules. Will never happen again.</comment></comment>