Ask HN: Going to lead a struggling dev team in a different culture, now what? - <AUTHOR> I'm flying in a few days to a developing country to lead a team of software developers. They are struggling with a project and the deadline is close. I accepted this contract because I like the country, the CEO and want to push myself to a first experience software lead.
One reason to bring me in is to implement good software development practices to the team. They are seriously lacking on this aspect: no test, a single staging dev server (no local dev env), no doc, inconsistent function and variable naming, the list goes on.
On the cultural aspect, the team is certainly stressed and I wouldn't be surprised if a few members will be defiant about seeing a Westerner joining the team that late in the project. Depending on how the CEO will introduce me to the team, I'm either the boss, am respected by default or another team member with no authority at all and can't rely on status to move things forward. Hierarchy is extremely important to this culture.
I can't just impose things: I need to sell good practices to the team so it becomes the natural next step to implement them.
It's going to be hard to implement a full software dev pipeline in such a small timeframe but I'd want them reach the point where:

  - the project is shipped
  - they understand why naming is important
  - they modularize their code
  - they do stuff for a reason (no meaningless SO paste)
  - refactoring becomes a reflex
 My solutions for this:

  - mandatory code reviews, especially my own code. It seems to me like a good way to show the team how you refactor code properly, will make me meet and talk closely to the devs and will, hopefully, inject a sense of collective code ownership.
  - making it very clear from the very beginning that *I* will be the one to make efforts to make myself understood: I know that some of them have a below average English level and are not comfortable to speak to foreigners
 How would you handle this situation ? What first steps would you take ? <comment><USER2> "no test, a single staging dev server (no local dev env), no doc, inconsistent function and variable naming" \--> none of these things prevent code from shipping, per se. I know it's convenient, as a first time leader, to focus on the technical aspects, but from your description, it seems there's underlying _non-technical_ issues you might want to get familiar with first.

On the technical side, I recommend _listening_ a lot before making any suggestions. _Maybe_ it's all backwards, and there's _always_ a better way to do it, but showing them you understand how they work _first_, then help them push something - even a small win - out of the door _first_ will get you a lot more "street cred" than trying to mandate things out of the gate.

If you're looking for some literature, "Five Disfunctions of a Team" and "Culture Code" are good starting points on how to tackle cultural aspects (and how to be accepted as a newcomer "playing the boss", which will also be your case).

Other than that - leading teams is difficult, leading teams _well_ is an incredibly frustrating/counterintuitive exercise, but a huge growth position :-) Good luck!

<comment><USER3> The first thing that crossed my mind was "Seek first to understand, then to be understood."

You almost certainly will find some people who already long for what you're going to advocate.

<comment><USER4> IMO this would be best. Don't go gungho and fix everything when you first join in OP.

</comment></comment></comment><comment><USER5> I think you are setting yourself up for failure:

> Depending on how the CEO will introduce me to the team

I'd resolve that NOW, before you fly out. If the culture is hierarchical, and you are supposed to be the "lead", but you aren't introduced as such, you are dead in the water IMO.

> They are struggling with a project and the deadline is close...I need to > sell good practices to the team so it becomes the natural next step to > implement them.

This is an awful combination. You are going to try to implement best practices, on a team that has little/none, who may not even believe in them as beneficial, while they are under stress to hit a deadline?

> I'm flying in a few days to a developing country

I'm sure there is more context to this situation than what can get in a summary. But honestly, if you summarized it well, I'd cancel the ticket and find something else to do. The way you have described it, I think you are in a no-win situation.

<comment><USER6> I agree, it's tough.

Not much to do really, but if I would do this, I'd stay away from changing the methodology and the code, and make it clear that it will be tough to make this fly.

Focus on:

Reduce scope. Make sure only the important features are built. Set up periodic meetings with all stakeholders to prioritize (down) features and subfeatures.

Get a grip on what's built and what's left. Make a realistic prognosis and make sure to anchor the new realistic target date with the stakeholders.

Make sure bugs and tasks are tracked. Set up manual testing routines with some experienced testers. A big team if the automatic tests are of low quality. Iterate and prioritize this list constantly.

<comment><USER7> This! Don't introduce new "best practices" in crunch time when you still don't have context yet. Give it 6-12 months and start by asking what the Dev team itself wants to change, not you.

</comment></comment></comment><comment><USER8> As an experienced manager, I shudder at the thought of pulling this off. But...

 _and want to push myself to a first experience software lead._

Am I to take this to mean this is your first experience leading a team? If that is the case, you are being set up for failure so that the CEO doesn't have to take the heat. "I brought in a high-dollar contractor, she was supposed to be good, but I guess not." If what you describe is accurate, and I'll bet there is a _lot_ you're not being told, Jesus Christ himself would look at this situation and say, "Sure, I can raise the dead, but this project, I dunno..." An inexperienced manager in a new culture in a different country? Yeah, you might want to cancel that plane ticket.

If I'm misreading your situation, feel free to ignore all of the above. But even if you're experienced, mmmm, I personally wouldn't do it.

<comment><USER9> Couldn't agree more. If the situation is as reads, OP is being set up as a scapegoat. Maybe not maliciously, but it stinks of last ditched efforts to avoid personal failure by the higher ups.

I wouldn't take this job and I absolutely love a challenge.

You don't send a first time manager to save a failing project at the last minute. You'd send an experienced one and use the first timer to fill in gaps on easier projects if needs be.

I really hope you rethink this OP, there's lots of good comments here.

Again, there might be more to the story so insert disclaimers here.

<comment><USER10> Also, remote teams can be a world of difference. Even if you're pure of spirit and think countries are just lines on maps it's really unlikely that they see it that way too.

</comment></comment></comment><comment><USER11> I'd go about it like so.

1\. Start on a high note, take the team out to lunch / dinner and start to get to know them.

2\. Don't force any changes, they will likely resist and you'll lose any budding support. Forcing a code review workflow is likely to demoralize them, and will be perceived to be slowing down dev that's already behind.

3\. Work longer hours than anyone. You need to earn their respect, being seen to work insane hours is the fastest way to prove your commitment.

4\. Do one on one interviews with everyone, and listen listen listen. They know what's going wrong.

5\. Strive for consensus, and become their champion in relation to upper management.

6\. Never denigrate any member of the team, even if they are exceedingly incompetent. Work with them to assign tasks they can complete.

7\. Heap praise on every good process and success you see.

8\. Never claim any credit for yourself, ever. Make sure the CEO understands this, and doesn't praise anything you do in front of them.

<comment><USER12> #3 - in some cultures a subordinate worker will almost always choose to leave after their superior. This is probably not the outcome you want/expect.

#8 - you need to find a balance between crediting your team and making it absolutely clear to management that your contribution was critical. Obviously you do want to avoid the latter in front of "your team"; but in closed doors or in management-only meetings, you should not sell yourself short... which means sometimes you need to just boldly say, "I recognized X and chose to guide the team to do Y, and that resulted in Z (a good outcome)".

<comment><USER11> For #3, my thought would be working from home and on the weekend. Committing code, updating tickets, emailing outside of work hours. Management type tasks are easy to handle off hours like this.

As for credit, yes totally agree. In a group setting, they should be the first to take blame and the last to take credit though.

</comment></comment></comment><comment><USER13> You are going to a war-time scenario (desperate crunch mode to ship a product), don't start to establish peace-time practices like code quality at the same time.

First, make sure that the situation is a war-time scenario: hard deadline (they rarely are) and shipping something (that enables sales, financing round or collecting customer feedback) is more important than shipping the right product.

In the war-time scenario focus is the key: reduce scope and ship only the bare minimum. This is as much managing up as managing down.

Get to know the team quickly, understand each members strengths and weaknesses. You likely need them all to succeed.

Daily task management and follow-up is essential. In the war-time you lead by asking questions and making orders. Prefer former, do latter when needed. Many (but not all) people like structure when under stress, so set it up if it doesn't exist, but don't let it restrict them to perform. Get people excited about shipping: even if you know the product is not great when the team will ship it, try to have a few shining parts there that everyone can be proud of, even if there are tons of ugly parts.

</comment><comment><USER14> Hi Charles, what you are describing is what I specialize in (outsourced/offshore software project rescue). I run a 4-part audit/assessment:

1\. Client education, AKA managing expectations. Educating the client on the _principles_ and challenges of software development. Most know very little about this and it makes their job very frustrating. Every failure of consulting is really a failure to manage expectations.

2\. Communication. How are they communicating, what are the problems? This is the most important thing in software development (and business in general).

3\. Methodology review. How are they managing the project? What methods and tools are they using? Are the tools configured, integrated, and automated correctly?

4\. Developer practices. Mostly based on my programmer productivity talk.

You are focused on #4 (and some of #3), which is important, but I find the first 3 way more important for "success." #2 sounds like your biggest problem. When I hire developers (always 100% remote) I prioritize two things: communication skills and discipline.

I'll give you one tip: static code analysis tools. This way the tool is criticizing the code instead of you (of course, I agree with code reviews). When I realized how useful this is I started giving talks on it.

Also, Gerald Weinberg's The Secrets of Consulting is gold: [https://amzn.to/2JvDZnx](https://amzn.to/2JvDZnx)

</comment><comment><USER15> The main thing to realize is that this is primarily a people-based challenge, not a technical challenge. There's actually a good chance that some of the team members know better practices but feel like they don't have time to implement them.

I would start by having one-on-one conversations with each member of the team to understand what they think the current problems are, what they think solutions might be, and what they think the team's current strengths are.

Then if you want to implement a solution, you can speak to things team members specifically told you. For example, if several people complain that they feel like they don't know what changes other people are making – that's a great time for code reviews.

The root causes for those problems can come from other teams as well. I once led a team that had a terrible codebase. Upon talking to the engineers, they had a pretty good idea of how to write good code, but were stuck with a legacy codebase and management would never let them take time to refactor. So I went to the CEO with a description of refactoring projects, how long I expected them to take, and how much time I expected them to save. Translating it into dollar terms made it much easier to get his agreement.

Above all, remember your employees are smart and probably have good ideas for any "obvious" problems – so you'll have to dig a bit to find the non-obvious root issues.

<comment><USER16> >>> The main thing to realize is that this is primarily a people-based challenge, not a technical challenge. There's actually a good chance that some of the team members know better practices but feel like they don't have time to implement them.

Not necessarily in this context. The project was outsourced abroad, probably to the lowest bidder. It's possible that contractors were sold as developers but have never developed anything before and don't know any good practice.

</comment></comment><comment><USER17> You're probably getting hired just to get this thing out the door, not to spend sixth months training a team in agile development processes.

The fact that you're making this post at all indicated you're assuming a lot of what the CEO requires/desires of you. Make sure you didn't make a gross misjudgment of that. And hopefully you're getting paid a lot.

</comment><comment><USER18> Cancel the gig.

You can not fix prior mismanagement with technical means and definitely not by bringing in an outsider who probably also does not speak the local language.

In addition you will be limited in who you can hire locally if this is the first time you are moving to a particular country. You will not have connections that are necessary for identifying and retaining high quality staff, should it be found that there has been some sort of acrimonious interactions between the CEO and his/her local team which has impacted morale, which essentially requires you to replace the entire team in order to fix.

So in your situation, you might be forced to try to fix the local team which is a coin-tosser (50/50 chance of this working out), and entirely not acceptable if an artificial deadline has been established.

Cancel the gig. Save the money you would otherwise have spent, and go on a vacation in the same country if you must.

Now, if you're mad and still want to proceed, you might do well reading [https://www.marshallcavendish.com/marshallcavendish/genref/T...](https://www.marshallcavendish.com/marshallcavendish/genref/The- FirstTime-Manager-in-Asia-revised-edi_B978_Singapore.aspx)

</comment><comment><USER19> I think it depends on what the CEO is really hiring you to do. Is it to turn this team around, so that it can take on projects in the future without stalling out? Is it to finish the project in as quickly as possible? I would recommend talking to the CEO first to figure out exactly what he's expecting from you, especially given that it's a hierarchy-oriented team/culture.

In my (and others', from reading other comments) experience, it is pretty unrealistic to swoop in and fix everything at once. You need to establish what you are being asked to do, and then make a reasonable step by step plan. Changing attitudes about software development is very difficult and you need to have a plan.

</comment><comment><USER20> I've been in similar situations in the past a few times and did a talk on how I did it.

Video : [https://www.youtube.com/watch?v=eYzk2BKeG9s](https://www.youtube.com/watch?v=eYzk2BKeG9s)

Blog Post :[https://www.hibri.net/2016/06/18/continuous-delivery-rags- to...](https://www.hibri.net/2016/06/18/continuous-delivery-rags-to-riches/)

There is no one way, every team has been different (for me), it what technique you use depends on context. They key themes that stand out for me are

1\. Limiting Work in Progress (focus on delivering one thing at a time), creates slack time, to learn new practices and start writing tests.

2\. Focus on learning, don't expect everything to fall in place pretty good ( it took us about 3 months to even to get to a good starting point)

3\. Pair and help them out.

<comment> bjelkeman-again Also, don't be surprised if the team was given a project which was really hard to deliver with the team's capabilities, and the CEO or his team leader, should have recognised that in the first place, and they (CEO etc) will be hard to convince that they are part of the issue.

Also your list of things look like something that would take a rather long time to implement (many months), especially if you have a late project to deliver on at the same time.

<comment><USER20> There is a fine line to tread to make these changes whilst delivering. There was never a point were we stopped everything to make all these changes. The changes have to happen gradually, and they do take a long time, many months. It involves changing people, teaching them new habits and helping them do it. The habits have to be sustainable.

Limiting work in progress, forces the issue upstream. Managers are forced to realise how much of a precious resource the team is, and why they are struggling. Throwing more work at a struggling team makes it even worse.

</comment></comment></comment><comment><USER21> _Depending on how the CEO will introduce me to the team, I 'm either the boss, am respected by default or another team member with no authority at all and can't rely on status to move things forward. Hierarchy is extremely important to this culture._

You really shouldn't sign any contract without knowing your compensation, role, goals[1], and position. It sounds like you really don't have a handle of what your exact position is and the role you will play is really dependent on that item. It might be impossible to achieve if you are relying on making a logical argument to carry the day.

1) some folks would rather say "deliverables"

</comment><comment><USER22> Some things that have helped me manage teams and projects going sideways:

Learn about their positive and negative experiences before changing anything. People are rarely as dumb as you think and often have to follow the instructions of their former dumb managers. Don't be another assumptive manager. Anonymous feedback forms during meetings are great for questions.

Position yourself as not their boss but being there to serve their needs, find how to support them and ultimately have the project succeed. Many employees are used to being mistreated overseas, some may not be able to handle this as they don't get moving until yelled at, others will cry out of happiness of dignity and respect. Strong emotional breakthrus are needed for turning around a project and for trust to form.

Make change plans together so the change is managed and there is an ownership in continuous improvement.

Create a culture of learning together and providing lots of mentoring and training that they didn't get in the past.

Reduce the culture of fearing mistakes and introduce one of learning. Lunch and learns are helpful to say this week I messed X up and learned Y from it. Do it yourself too.

Get lots of resources to help them learn in their own time. Lynda.com,etc. Make it clear your are here to help their personal and professional development first because that will get everyone positive results on the project.

Set the bar for work ethic. Nothing will move unless you do. You will find people who align with your message, or those who don't, and it may be required to replace some folks.

Rather than get into painting the sky magical colors, if your remaining project scope is known, implement a ticketing system like Jira with a basic workflow to teach the team how to record and build the defects. That will likely get more done to start a change that you can layer agile, etc with in the future.

</comment><comment><USER23> A lot of good points here, so I'll try not to be redunant. A lot of the best practices you have listed are longer-term investments and culture changes. If you just need to ship a project, then you and your team will need to figure out how to make that happen, even if its full of ugly hacks. After its shipped, then you'll have more leeway to start fixing bugs one at a time.

It also sounds like there's a huge political element here too, so of course be aware of that. Definitely don't try to rock the boat too much at first until you understand specifics of what is wrong. Overprescribing can be demoralizing, and if the project still goes south then you're the one to be blamed, since it was your idea to "change things". Not to say you should do nothing, its a delicate balance, and one I would certainly struggle with myself. Best of luck.

</comment><comment><USER24> It sounds like you already have the problem and solution in your mind before you land. Even if you end up being right it might be good to approach the problem with a black slate and do discovery as if you know nothing rather than with an agenda.

The other factor to be aware of is when people's income and livelihood is at stake they will fight tooth and nail about everything. If you give the team ownership in creating the solution and make it about co-creating the product you might have better long term success.

However, if the deadline doesn't permit that, then the short term solution is to map out a process like you described and find out who's on board and who's not. Remove those who offer resistance from the team because an anti-team player is death for a deadline.

</comment><comment><USER25> Personally, unless you're paid well enough to be a very comfortable sacrificial lamb in this situation, I would walk away from it. This has "fall guy" written all over it.

If hierarchy is important in that culture and you're not introduced as the new boss, you're pretty much dead in the water from day one.

As other posters have said, until you figure out why the project is late (bad project management, unrealistic deadlines from the start, not the right people, trying to hit a moving target), going in an prescribing a cure without understanding the nature of the problem isn't going to get you anywhere.

</comment><comment><USER26> You have to be conscious of what has _caused_ the lack of these things, things like tests and staging rules that you might normally implement at day-zero.

It sounds like they've been poorly managed, not necessarily just in getting people productive, but in pushing back. A manager who serially misses agreed to timelines is usually a yes-man. Might just be a character flaw, but some cultures —especially in parts of Asia— are taught to be yes-men. Doesn't matter if it's a lie, make the sale, fix problems tomorrow. And that's an important issue when you're dealing with remote engineering, which is often twice as hard to scope out anyway.

So whatever your goal to befriend or get respect from these developers, you _have to_ work out how realistic their estimates are. You might actually be nowhere near a product.

It may be that by the time you've worked out the situation, the actual capacity of your developers, you need to have a candid conversation with management to pull the plug. If you can do that efficiently and escape with _something_ , awesome.

If they're competent but just historically over-stretched by their ex-manager agreeing to crap they could never complete in time, you have a lot of carrot to offer them. Better working conditions. Better education. Opportunity to stuff their CVs with value, instead of continuing to work bug to bug to get a job done.

But yeah, attempting to deliver without fixing any of this would be a tough one for me. I'd have so little confidence in the code before handing it off to QA. I fear the idealist in me would make it my first job to set realistic expectations with upper management and push these deadlines until you're up and rolling.

</comment><comment><USER27> The first thing I would do is check your own personal network to see if you know anyone that grew up in the culture of whatever country this dev team is in.

In my experience, as far as culture, you really don't know what you don't know. So it could be very helpful to get a brain dump of advice. Even if they the person that advises you is not technical they could likely offer a lot.

<comment><USER28> ^ this.

"find a friend to be your senses" is my wording of it (from long ago).. And do this in all possible aspects (of culture or else) - common-people, company/companies, devs, management.. and once and again.

Technical stuff might be in dire state but is usualy fixable... unless people/culture simply prevents it. So beware.. esp. of things you are not told, like why these devs, why this project, why finish it, why now, .. why you?

Fish starts smelling from the head first.

and... Westerners might not be too welcome everywhere. Watch and Listen.. before doing anything. YMMV

</comment></comment><comment><USER29> I think this is an unwinnable position. Software projects are multi-faceted and you've taken on the role as the savior- it's not just lack of tests bringing this team down.

I wish you luck but don't beat yourself up if this doesn't work out. This sounds like you're setup to fail.

</comment><comment><USER30> Im afraid I have to agree with the negative comments, chances are its going to be a complete disaster. But I ignored similar advice once and had a great time! :D

My suggestions (SEA exp):

\- Brief your CEO on how she should introduce you. She should big up your background, your skills, your accomplishment. Make it clear your here to help. And if she is good she will pitch it in a way where your not appearing as a firefighter or saviour.

\- _Start by telling everyone how unbelievably good they were to get as far as they did._ Its likely they were working their asses off at bad salaries and poor communications. The last thing they need to hear is how wrong they are getting it.

\- The things you mention about hierarchy is ridiculously dependant on geography. The right thing to do in Bangladesh could be the absolute worst thing you could do in Indonesia. Both are hierarchical, but in extremely different ways. You need location specific advice!

\- On the actual improvements just do whatever is practical to ship the product. Try to see why they were tripping up on the basics and help them sort it. If its extremely poor skills get your CEO to cough up and start bringing on good guys to help teach. If its because people are pissed ease off the pressure and improve the working environment.

A final note. Of the dozens of foreign owned companies in developing countries I have encountered - I cant remember a single time a bad dev team was not as the result of poor management. Typically from the foreign component or their direct reports. Skills can be improved but only in the right environment.

</comment><comment><USER31> 25 years ago I was given a similar possibility. Building a large team from scratch in an emerging country.

There was a huge difference though : the company was international, had plenty of money to burn and I could fail without consequences (as I see it now).

And boy, I failed. A few times.

The experience was extraordinary and it forged my future. I am today in a position I would not be in if not these years and other similar opportunities all over the world.

Let me please emphasize two thingd:

\- I was allowed to fail (it was somehow expected)

\- and I failed.

You have no experience in management, and especially not in international management. Therefore you will fail. And learn a LOT.

If you are going there to learn AND fail - do it. It will be an invaluable experience.

If you plan to succeeded, or at least may be impacted by failing, do not go. Get dome eaqier experience first.

Having important work to deliver + problematic team + other culture + inexperienced leader = disaster. Yhis means either clueless company or a need for a burnout manager to sacrifice.

</comment><comment><USER32> Read The Phoenix Project book in the while you have to go there, and all of your questions will become clear.

<comment><USER33> Great suggestion. No quick fix in there but does help set the context...

</comment></comment><comment><USER34> I didn't see this mentioned elsewhere but I would also start by getting a handle on all the outstanding tasks:

If there are tickets, read and understand all the tickets, organize them in a way you can manage day-to-day.

If you're working off some other spec, start breaking it up into individual tasks that can be managed on a spreadsheet or in a ticketing system.

If you're working off general guidelines without documentation (and you can't run!), start by writing out all the tasks that need to be accomplished to finish the project. Even if they are brief.

Now take the list of tasks and organize them into 2 "types"

Stories: Tasks that deliver value to the end user

Tasks: Tasks that are required or nice to have to enable 1 (Tasks or Chores)

Now prioritize those into different buckets

1\. MVP: if we don't ship this, the project will fail

2\. Nice to Have: Someone _really_ wants this but it's not MVP

3\. Phase 2

The more scope you can put into bucket 3 the more likely you'll be able to deliver _a_ working, functional project on time. You will get more credit for delivering something _good_ than failing to deliver the perfect project.

Your team will also thank you for taking significant stress off their plate and for making them a success.

</comment><comment><USER35> Focus on results. I'm leading a team that wasn't delivering for quite some months. We had couple of sessions on why we didn't achieve our results. We used the 5 why method to find the root cause of problems. Once we tracked the root of the issue, long pull requests became more manageable, we started communicating better. We focussed on what we produce and eventually were able to achieve our goals. Smart Leaders, Smarter Teams[1] is a good book to read. His white paper is a shorter read with similar topics: [https://www.csu.edu.au/__data/assets/pdf_file/0008/917018/Ei...](https://www.csu.edu.au/__data/assets/pdf_file/0008/917018/Eight- Behaviors-for-Smarter-Teams-2.pdf)

1\. [https://www.goodreads.com/book/show/16305347-smart- leaders-s...](https://www.goodreads.com/book/show/16305347-smart-leaders- smarter-teams)

</comment><comment><USER36> Do you speak the language / know the culture like a native? That is bound to help you.

I see another poster talking about expectations. You need to be clear with the executive team on whether this team can be successful given the expectations placed upon them. Most underperforming teams I've seen have been more the result of unrealistic client/ownership expectations.

</comment><comment><USER37> I've hosted a 30+ of couch surfers over the past year. They crash on an air mattress in my studio apartment, so it's a tight space. Even though they are grateful for a free place to stay here in San Francisco, it's easy for me to say a very western things that my guests misinterpret.

For example, the word asshole. To me, asshole does not, and never really did, mean the hole in one's butt. Asshole means jerk. At least it did until I hosted someone from South Africa. He told me that in South Africa, my language would be considered very profane profane. To him, asshole ONLY meant (still means?) butthole. There was no overlap in how we understood the word.

So I recommend keeping your language as neutral as possible, relying on as little idiomatic wording as you can. Say jerk, not asshole. Say it's raining quite harc, not it' raining cats and dogs, etc.

</comment><comment> trevor-e It sounds way too late at this point to worry about stuff like modularization and refactoring. Many of the things you mentioned are certainly important for long-term success, but it sounds like you were hired to impact the nearing release so I'd focus on that first.

I would start with the infrastructure stuff like you said, a staging server and CI. If every dev has been relying on local builds, this will probably find a bunch of issues right off the bat.

After a stable build environment is established, I would go over the bottlenecks they currently face and work on freeing those up so they can work more efficiently. Since you're so late to the game, you should focus on enabling them to work faster to hit the deadline. All the other methodology and code quality stuff you mentioned can come after that.

</comment><comment><USER38> There's a lot of unknowns here, but here's what I'd do. It reflects some of the top comments:

1\. Know your goal. If it's to meet a deadline, then documentation, refactoring, or any other quality of life tasks won't move you closer. If anything, it will sow confusion and make the team more stressed. Leave that for post-deadline.

2\. Focus on the stress. Spend time with each team member 1:1 to figure out what their stresses are. Come up with a plan together on how they'll address it. Make sure they feel it's the right plan.

3\. Leadership isn't something that comes from title. You earn it by being the person the team looks up to. Teams look up to the person that sticks up for them and makes them feel powerful. In my experience, that transcends culture.

</comment><comment><USER39> There's lots of great advice here, one more thing I would add is make it clear to the CEO up front that the deadline will slip. I would make this an absolute and get the new deadline in writing, because if you use weasel words then the CEO may claim that they misunderstood. Make it clear that even this new deadline may change as your understanding of the situation develops. You should also be the one to deliver the good news about the moved deadline to the team. If the CEO is unwilling to accept this, then you should probably walk away, because it suggests that they're still in denial about what is happening.

</comment><comment><USER40> You may get some inspiration from [https://www.codesimplicity.com/post/how-to- handle-code-compl...](https://www.codesimplicity.com/post/how-to-handle-code- complexity/)

Excerpt:

> It's very tempting, if you're a software engineering manager, to propose > broad, sweeping solutions to problems that affect large areas. ... > > So > what can you do as a manager...? Well, the trick is to get the data from the > individual contributors and then work with them to help them resolve the > issues.

</comment><comment><USER41> I would suggest that despite the country or the company or the culture you are working, you have to lead by example that means first you have to work hard to prove to the team that you are capable to lead them, both technical and leadership.

When you lead by example, you set the standard for code, design patterns, documentation, etc. and as you go along build the tools, infrastructure, processes and culture.

Don't expect to change everything overnight, it will take time, be patience and you have to trust people you will be working with.

</comment><comment><USER42> If this is a hierarchical culture, I worry that the changes you propose will be seen as a slight to whoever was in charge before you. Consequently, if I were you, I'd go in as a teammate and get something out the door to build camaraderie. Then, have an open meeting where everyone talks about the project, what is working well and what isn't working very well. I'd frame it as if there is nothing wrong, but that you could work together to improve things.

</comment><comment><USER43> You haven't even landed and you already have a solution in mind? The things you list are long term goals and very cookie-cutter approach to running a team. This might not go well for you if you expect to project your ideals onto other people on the first day; especially a team that is already burnt out. I would seek to understand the situation first from the team because from you description, it seems like everything you know about the team came from the CEO.

</comment><comment><USER44> Reading through the comments already made, a grim picture is painted for you. I agree with what @mikestew wrote. If you do happen to go forward with this then I would suggest; focus on helping the team ship the product, not changing the process (it seems to be to late in the process to make fundamental changes to mindset). After you've shipped, then you can discuses best practises and whatever in a retro and probably plan a refactor of some sort.

</comment><comment><USER45> Can you fix the formatting for this to not include code block formatting for the lists, especially the second one? The side-scroll is unbearably long even on a PC.

</comment><comment><USER46> > or another team member with no authority at all

"Responsibility without authority is like being up a creek without a paddle."

If you are expected to make improvements, you must be granted to power to make changes. Otherwise neither your needs nor the company's will be met.

The current situation is apparently not working, and simply throwing bodies at the problem is likely to make it worse. Insist on a level of control minimally equal to the things you must deliver.

</comment><comment><USER47> That seems like a very nice experience! You'll have to manage your personality to not come off as know-it-all type of guy. The best I can tell you is to try to understand each one of the developers as a person with feelings and explain everything with love. That never fails. Also How to win friends and Influence people is a book that couldn't be more special to this situation.

</comment><comment><USER48> Please, please, please pick up the book Peopleware if you haven't read it. It's a classic for a reason [https://www.amazon.com/Peopleware-Productive- Projects-Tom-De...](https://www.amazon.com/Peopleware-Productive-Projects-Tom- DeMarco/dp/0932633439)

</comment><comment><USER49> I moved from a developing country (where I worked 1 year in a software dev environment you describe) to the UK. So I know exactly what you are talking about.

Feel free to pm me if you have more questions

List of issues I can think of...

1- In some cases, people in developing countries usually have a short term thought/goal. Like myself. I'm just here until I can apply for Masters in xyz country or immigration to lala-land and get out of here. Brain drain is very very real and very very obvious. People change far too quickly. And because there is no handover/software dev process. A lot of stuff is re-done.

2- We just have never ever seen good practise/experience to know any better. In the UK, there were people next to me who had been engineering for 20+ years! I didn't have access to that level of engineering/experience. I'm talking about Engineering, 20 years of coding/design experience of building/shipping stuff. The senior guys are still there. They just drift to management as engineering is dirt cheap.

3- I'd recommend listening a lot at first. There will be one or two good people who others in that team will be looking up to. Focus on those guys and explain your changes to them. They'll explain it to their fellows in their language. And there will be quiet people mostly because of language barriers.

4- Take baby steps. (or one big drastic step)

5- We don't think in English. That becomes a problem at times because people in English speaking countries think in English, learn code in English, speak in English etc. We might know English. And we write text/code in English. But we actually think in our own Mother tongue. Hence the focus on convincing a few key people who others are looking up to. And then they can talk in their language.

6- Build trust

7- Sometimes the gentle approach doesn't work and you need to use the stick approach. This is how its going to be done. The CI system is going to enforce this policy. I'll do all merges and this is the list of things you need to make sure work before sending a PR.

8- Establish your role with the CEO and make sure the CEO communicates everything to the team. Including the fact that there will be some time invested in improving software methodology itself. Otherwise, you'll be in a constant battle for justifying things.

9- In the developing countries, overall, people are in a higher stress state. It can be any number of things most commonly financial stress, family social issues, marriage issues.

10- Age matters here. Not technical/expertise. And if a bunch of people came from one University and another bunch from another, it matters.

11- Notice who eats lunch with who.

12- Build trust. Learn a few words of the local language. Try to say a few words. This usually results in a bout of laughter though.

I can probably go on n on. But I think you have enough

<comment><USER50> Be careful of not generalizing, I have lived in several "developing" countries and at least half your points wouldnt make sense there. I would say treat them as you treat an american team with some allowance for language/culture differences.But that's it.

</comment></comment><comment><USER51> > I accepted this contract because I like the country, the CEO and want to > push myself to a first experience software lead.

I suspect that you are young. Only a young/naive person would take a job on these points. From my perspective from a 40+yo (with 20+ years exp), this is very foolish.

> They are struggling with a project and the deadline is close.

You should really tell us the backstory. Unwittingly, you have made yourself the fall-guy. Now your "boss" can surely put the blame on YOU when this goes south.

> They are seriously lacking on this aspect: no test, a single staging dev > server (no local dev env), no doc, inconsistent function and variable > naming, the list goes on.

I hate to use the word incompetent. But lets call a spade a spade shall we? In the little to no time you have, you cannot expect to work miracles overnight. Especially when you are so new to being a software lead.

Talk to the wrong person, in the wrong way and it's all over. Depending on where you are going. Losing face is quite serious in some places of the world.

What happens if you get into a situation where they cannot say no. So instead they say, not now or maybe it isn't the right time to implement X. Now you've stalled and the project fails.

Honestly, my advice would be to walk back this situation as best as you can. You want your first project lead to be a simple project that can be controlled and taken from conception to shipping with the least amount of issues.

Not this baptism of fire, which you WILL get burned. There are so many variables in play that you won't be able to control ANY of them!

> How would you handle this situation ?

Very simple. Talk to whomever gave you this assignment and tell them you have thought about it/taken outside council and it was foolish of you to accept.

Let the project fail. Let it fail very hard. Let the project owner bask in it's failure.

Only when you are asked to rescue the project, then you can submit a document detailing how it could be rescued. How long it may take to do so, the budget, the team members you need, etc, etc. You make it clear that it's only an estimate since you have not seen the codebase.

Then and only when you get the codebase and do a thorough examination of it, then you submit a revised proposal.

If you are successful in a bid to rescue it. Once you have control of the project you can implement your dream wish list, etc.

If you are unsuccessful in getting the project. Well, let it burn. It's not your head on the chopping block. Move on, that project lead will come some day.

</comment><comment><USER52> This is a _people_ problem. Not a technology problem. First _really_ listen to them. Understand their culture. How they think. Why they do what they do. If you don't you will fail.

</comment><comment><USER53> One thing to consider: If there's an area of code you think is suspect, hold review meetings. Keep the meeting to 3-4 people.

They're also a good way to learn when your suspicions about bad code are wrong.

</comment><comment><USER54> Meta: these posts are a LOT more interesting if the person asking the question bothers to stick around to clarify, discuss the answers they're getting, say thanks, etc.

</comment><comment><USER55> > What first steps would you take ?

Quitting the job immediately.

</comment><comment><USER56> I've just finished leading a company in SE Asia, so assuming you're somewhere near there, this is what I'd say from my experience:

\- don't worry about the usual western alpha-coder crap or any defiance. You'll be respected because the boss says so. They won't give you any of the shit that a western dev team would do while they work out the pecking order - the hierarchy is the pecking order. BUT... no-one will tell you the truth, they will always tell you what they think you want to hear. Only ask open questions (if they can say yes they will), don't ask for opinions (you'll get whatever they think you want to hear). If you tell them to do something stupid, they will never tell you they think it's stupid. They might not go and do it, and hope you don't notice, or if you do notice that you will realise that what you told them to do was stupid and you're not going to lose face by mentioning it.

\- Authority and hierarchy are massively more important and more rigid than in the west. I can't overstate this enough.

\- you will constantly run into communication problems. They won't tell you when they don't understand you, but will nod and say yes boss and then go do their best to guess what they think you said. Ask if they understand often, and do that by the patronising-sounding "what did I just say?" or "what did I just tell you to do?". It's difficult, because we only do this with children in western culture, but it's necessary.

\- Use email and written comms waaaay more than you would with a western team. It's easier for them to understand written english, and they can take their time over puzzling it out. And you have a audit trail of what you said (yes, they'll happily do the "you told me to do this" if they think they can get away with it).

\- You will get automatic respect for being western (assuming you're white that is - racism is real here). So I wouldn't worry so much about demonstrating that the practices you want to introduce have actual value. That will be taken for granted because they're western practices. Instead make sure they're understood. That will be hard.

\- If your boss is not western, they will expect total and complete obedience to their authority. Don't ever question them, contradict them, suggest alternative ideas, or tell them what they just told you won't work, at least in public and probably in private too. You will have to learn how to allow your boss to keep face while getting the right result.

\- listen a lot more than you think you will have to. If something's not working, there's probably a cultural reason for the fail that you're not seeing. Listen harder and you'll discover it. Often it's easier to let them do things their way even if it's slower and less efficient, because trying to get them to do things the western way is too alien to their way of thinking. It's surprising how often this is the case.

that'll do... you'll learn the rest as you go. Good luck :)

</comment><comment><USER57> Can you fire people? can you reorganize the team?

</comment><comment><USER58> It will be difficult and frustrating, but can be also fun and rewarding in addition. Here are some pracoval tips that worked for me in similar situations.

Treat everyone with respect - everyone has a story and being competent developer is not the only metric for human beings.

Reduce scope - better deliver few solid features than many half baked. You will need to get heavily involved in implementing those features so better not spread yourself too thin.

Start with authoritative management style - it's ok to say "do this and do it like this". Particularity with hierarchy based cultures, this could be even expected. At the beginning it can be uncomfortable as Western developers are often used to servant leadership style that supports freedom, outlet for developer creativity and individual autonomy.

Set precise rules - people are usually able to follow checklists and step by step guides. Have process ready and thought through, but tailor it to the situation on the ground. An example could be: implement task, write unit test with 80% coverage, build and run test locally with no tests failing, send for review.

Don't expect creativity - be as precise as possible specifying the tasks. Include design in the description, any names of the classes you want to have. Ideally have a pointer to code or example on internet that can be copy paste and modified. Specifying tasks this way is doubles the work it usually takes but otherwise you get into endless reworks and headaches. The level of detail needs you to be very well prepared in the technology, design and domain knowledge. Read up ahead on the stack they are using, patterns used for the type of app you are building, look at the code and get familiar with the domain.

Use the hierarchy - identify the one or two promising team members and with with them. Let all other team members consult them first and only then approach you. It's easier to work in depth with two people than get drowned in random questions from five or six.

Expect to get your hands dirty - you will still need to do lot of individual contributor low level implementation work to set standards and so that others have place to copy from. Your code needs to be near perfect the first time as it will get copied over many times. This is painful, but make it work now and refactor later often doesn't with great, when there are 5 people multiplying the work that needs to be refactored.

Distinguish the work from the person - it keeps amazing me how much I like some people on personal level yet hate their work output.

On the other hand this can be a great adventure, getting to know new people and country while working on a common goal. Crisis often bonds people together anyway.

Hope that helps and keeping fingers crossed for you.</comment>


Trump's New Silicon Valley Attack Could Turn a Brain Drain into a Lobotomy - <AUTHOR> https://www.vanityfair.com/news/2017/11/trumps-new-silicon-valley-attack-could-turn-a-brain-drain-into-a-lobotomy <comment><USER2> This entire attack on immigrants in tech is pretty disgusting. I'm curious on if there is real data driving this, or it's just some ruse under the guise of "maga."

</comment><comment><USER3> I even saw they were raising the minimum required to pay immigrants on an H1B from 60K to 90K which means a lot of jobs are going to either disappear or go towards big companies. It seems like a very wicked plan.

</comment><comment><USER4> Wonder which countries are going to rise out of this?

<comment><USER2> Rise? like which country benefits from this?</comment></comment>


Bypassing LastPass's "Advanced" YubiKey MFA: A MITM Phishing Attack - <AUTHOR> https://pberba.github.io/security/2020/05/28/lastpass-phishing/ <comment><AUTHOR> This point, mentioned in the article, bears repeating, especially if you aren't familiar with Lastpass or their 2FA:

Lastpass uses Yubico's one-time password, which is more similar to TOTP than it is to FIDO's U2F (which Yubico had a hand in). Lastpass has had this for YEARS, long before U2F was even a thing, or before Lastpass was bought by LogMeIn.

10 years or so ago (back when I was a paying user of LP), the Yubico OTP was a really nifty bit of security, and probably state-of-the-art, at least to a user like me. Now, not so much. I don't know if this feature has a future, or if there are any plans to phase it out, since U2F is more secure. I'm not sure if there are really any existing applications for it, but this isn't my field of expertise; there might be something novel that can be done.

What I DO know is that users of Lastpass have been asking for U2F as an option for several years now, with no real movement on LP's part. If a one man outfit like Bitwarden, or a famously reticent company like 1Password, can implement U2F, Lastpass has no excuse (to be fair, 1Password's reluctance to implement a second factor was understandable when they didn't have a cloud component in their software).

Unfortunately, the only thing that will likely move LP is if Yubico announces they're dropping the OTP feature entirely.</comment>


IPad 2 pixels - <AUTHOR> http://i.imgur.com/pKWgH.png

<comment><USER2> Their target market can't pay attention to that much detail. So the iPad's resolution is good enough for them.</comment>


Lifecycle greenhouse gas emissions of electric vehicles - <AUTHOR> https://iopscience.iop.org/article/10.1088/1748-9326/11/5/054010 <comment><USER2> TL;DR? "The size and range penalty (going from segment A to F) of the EVs was a 1.7 increase in lifecycle CCP impact".</comment>


Fab Lab Moves Downtown as San Diego Creates Its Own SoMa - <AUTHOR> http://www.xconomy.com/san-diego/2014/10/31/fab-lab-moves-downtown-as-san-diego-sets-out-to-create-its-own-soma/2/ <comment><AUTHOR> Excited to see SD start to find its entrepreneurial identity. While I think the SoMa comparison is unnecessary, there is a lot to say about the world- class creativity that exists in SD and the entrepreneurs that just need a little direction (including myself) and smart capital to bridge the divide between creativity and business.</comment>


I just finished crawling 5.19B web pages, Ask Me Anything - <AUTHOR> I WAS JUST RATE LIMITED BY HN, SO IM GOING TO ANSWER YOUR QUESTIONS UNDER A NEW ACCOUNT: dor_jack_2 <comment><USER2> If you're rate-limited, you can contact the mods via the Contact link in the footer.

</comment><comment><USER3> What tools did you use? What had to be custom-written and why?

<comment><USER4> We tried a bunch of technologies like Nutch, Heritrix, Storm Crawler, ... eventually settled on Mixnode and since it's a 'cloud platform' we didn't really have to change anything.

As for processing the data we crawled, we are using ArchiveSpark ([https://github.com/helgeho/ArchiveSpark](https://github.com/helgeho/ArchiveSpark))

Also, Mixnode defaults on Amazon S3 for storage which was ok with us since we're using EC2 for processing the results.

</comment></comment><comment><USER5> How much did it cost?

<comment><AUTHOR> It was an all inclusive deal: 420 TB at 0.06 per GB = $25,804

</comment></comment><comment><USER6> what did you do to avoid winding up in endless GET url loops? How deep did you get per site, and how did you schedule followup requests?

<comment><USER4> Loop/spam prevention was done by mixnode, I'm not sure how they do it.

The data does not follow a DFS or BFS pattern so pages/site varies greatly by a host's server capacity and anti-crawling configs.

There was a minimum of 10 seconds between followup requests to the same website unless robots.txt had a lower delay. Pretty polite...

</comment></comment><comment><USER7> Why didn't you use common crawl instead?

<comment><USER4> For our purposes Common Crawl's corpus was missing too many websites (possibly due to robots.txt configs of websites) Also we needed some deep coverage which CC could not provide.

</comment></comment><comment><USER8> What did you discover.

<comment><AUTHOR> We are processing the data as we speak. However the movement of technology based on where your company is based is truly incredible.

Will update this in a few days with more data.

<comment><USER8> That will be an interesting correlation to see different frameworks or tech or even design elements based on geographical location.

<comment><AUTHOR> If our company approves I would like to publish some general statistics that may be of interest to others.

</comment></comment></comment></comment><comment><USER9> but why?

<comment><AUTHOR> Our company is in the Marketing Intelligence (MI) industry. We needed to measure the penetration of multiple technologies in different countries.</comment></comment>


A Cherry Tree to Mars [pdf] - <AUTHOR> http://www.patrickmccray.com/wp/wp-content/uploads/2013/05/sagan1976_1of8.pdf <comment><USER2> The blog post [1] that links to the PDF gives some context to Sagan's talk.

[1] [http://www.patrickmccray.com/2013/04/30/cherry-trees-to- mars...](http://www.patrickmccray.com/2013/04/30/cherry-trees-to-mars/)</comment>


The ill-fated tale of Phoneys that went #1 on the App Store - <AUTHOR> https://medium.com/@ahow/the-ill-fated-tale-of-phoneys-the-stupid-little-sticker-pack-that-went-1-on-the-app-store-4934d4372352#.13rld2rsf <comment><USER2> Apple doesn't have the ability to kill an app remotely? Because otherwise this guy is telling me to spend a buck on an app that might disappear.

<comment><USER3> Apple has that ability ([http://www.telegraph.co.uk/technology/3358134/Apples- Jobs-co...](http://www.telegraph.co.uk/technology/3358134/Apples-Jobs- confirms-iPhone-kill-switch.html)), but naturally, it wants to use "the atomic option" only in extreme situations. I don't think they have ever used it. Certainly, [http://www.businessinsider.com/brazil-orders-apple-to-use- ip...](http://www.businessinsider.com/brazil-orders-apple-to-use-iphone-app- kill-switch-2014-8) claims it was never used up to august 2014.

I also would expect Apple would repay buyers if they ever did pull the switch, but don't take that as a guarantee.</comment></comment>


Tech billionaires award $25M in Breakthrough prizes to top scientists - <AUTHOR> http://venturebeat.com/2016/12/05/tech-billionaires-award-25-million-in-breakthrough-prizes-to-top-scientists/ <comment><USER2> Much better article about this at the Economist: [http://www.economist.com/news/science-and- technology/2171121...](http://www.economist.com/news/science-and- technology/21711211-yuri-milner-technology-billionaire-wants-turn-scientists)

<comment><USER3> Announcement at Breakthrough.org: [https://breakthroughprize.org/News/34](https://breakthroughprize.org/News/34)

</comment></comment><comment><USER4> I'm so thrilled that Harry Noller got this prize. he was my undergrad advisor and I learned biochem from him. His work on ribosomes has been great, and the fact he didn't get the Nobel (his competitor) did was always a sore point in the community.

</comment><comment><USER5> I really wish they would film/broadcast/live-stream this. It'd be nice to have some production behind it to make it apart of the general public.

<comment><USER6> Then they would need to get some hot actresses to present the awards. Sort of like the Oscar tech awards.

<comment><USER4> You mean, instead of Morgan Freeman, who was the presenter this year?</comment></comment></comment>


Google is making better apps for the iPhone than for Android - <AUTHOR> http://www.theverge.com/2016/7/8/12109832/google-apps-iphone-android-motion-stills-gboard-search-hangouts <comment><USER2> I'm convinced that people at Google don't really use their own Android apps much. There are fundamental obvious problems.

Two examples - "Play" Music puts a lot of effort into not playing. Anything less than a perfect network, or having played a song or two seems reason enough for it to stop. Comically the most common thing we see is an error dialog about errors streaming, that popup on the times it does start playing successfully.

The other example is Keep. I last made a change on desktop 3 days ago. Today outside the store I started the Android version, where it proceeded to show me the most recent items I added in the unticked section, but ticked. Ticking one of them then moved it to the ticked section, and caused another relayout where the content was bizarre, followed by another relayout about 10 seconds later that was correct. I've also had the ui lockup when there is no network connectivity, which seems a rather fundamental programming error. You shouldn't need network to tick an item in a shopping list!

<comment><USER3> The funny thing about Play Music is that the early versions were really solid. I streamed mp3 from my Google account while driving all the way from Chicago to Cleveland back when I had a Nexus S 4G, and Sprint's network was not what you would call perfect.

</comment></comment><comment><USER4> Isn't The Verge biased and very pro Apple? At least that's the stigma I read online that The Verge is basically Apple News.

EDIT: Maybe instead of downvoting, just prove me wrong.

<comment><USER5> I think, as a rule, the burden of proof falls first upon the claimant.

You have made a claim with no evidence to back it up, only hearsay.

This is why so many who frequent HN include citations for even trivial comments.

<comment><USER4> Well, I was asking if that claim I read online is true or not and if it should be considered if The Verge is biased or not. That is all I tried to do!

<comment><USER6> If you're getting downvotes (none from me), it's likely from exasperation that anyone is even bringing this up in the first place. Read comment threads on the Verge where people complain about bias- they almost always appear to be written by toxic high school kids who draw way too much of their self-image from which gigantic corporations their parents have bought their devices from.

The comments on the Verge used to be at least a little better than those on Engadget/Gizmodo/etc., but they've mostly devolved into the usual prepubescent Markov chain noise floor that article comment threads on the internet always sink to in time.

</comment></comment></comment></comment><comment><USER7> From my limited mobile development experience, this probably has a lot to do with the same old story for Android: fragmentation, and the fact that iOS is tailored to a limited set of hardware.

Less time fighting the platform means more time to make a great app experience.

<comment><USER8> iOS 9 adoption is around 90%.

[https://mixpanel.com/trends/#report/ios_9](https://mixpanel.com/trends/#report/ios_9)

That makes software development much easier. ios 10 will reach the same adoption level by this time next year.

</comment></comment><comment><USER9> This is a direct result of the Android API's being fucking bizarre.

It's been quoted that they expected Android development frameworks to be built on top of them, so they didn't make them developer friendly - but they also reach up so far (see the Activity / Fragment nightmare) that it's complicated to make a development framework on top of them.

</comment><comment><USER10> I tried an android for a couple of weeks recently, I tried it using the "Oneplus 3" as it was good bang-for-buck and ran the latest software with plenty of grunt. Hardware wise the unit is lovely, not as high build quality as my iPhone 6s+ but not nearly as bad as the Samsung Galaxy S3 I had tried in the past. The OS looked pretty... at first, then I started installing apps and it very quickly felt messy. I noted that the general 'quality' of android apps felt quite poor. Nothing seemed to integrate very well, if at all and a lot of apps felt like they hadn't been maintained for quite some time despite being the 'the best option' available.

I had a go at disconnecting my from the clutches of google first by trying not to sign into any of their applications and disabling all the information reporting in settings, I felt like y was a bit like how iOS was back in the iPhone 3G days when you had to root the phone to do half the things you wanted.

I then ended up flashing a custom rom that was pretty much stock, but without the good stock apps, I had to install the google App Store and create an account which I think is fair enough because I couldn't be bothered dropping custom downloaded apks and using that dreadful android transfer tool from my laptop which seems to work 4/5 times you plug your phone in, but like a lot of the apps in the ecosystem - felt very 'javaish' (pun slightly intended).

Anyway, I'm going to wait for Fedora or similar to becoming installable on the device then use it as a mini server / portable desktop because android just feels so fragmented and I can't help but feel like I can't trust the platform or the company that created it.

Hardware wise the OP3 felt like it was design with more care than any other Android phone I'd spent any fair amount of time, I love that it uses a USB-c port but was disappointed to find that it was actually only USB 2.0.

<comment><USER11> I use both ios and Google's stock Android. I would say they are both just as "messy" although it seems like I can integrate with other apps easier on Android than ios. Perhaps you were running into issues with non stock is? Perhaps you need to find better apps as well. The video editor I use on Android is better then on ios. Fb on Android is almost as good, although the app wont upload HD video. But really there are pros and cons of both, especially now that I can use swipe on ios.

</comment></comment><comment><USER12> I'm hoping Android without Google takes off, and we can get a good ecosystem no matter whether GApps are good or not.

<comment><USER13> I'm hoping sailfishos takes off.

</comment></comment><comment><USER14> They don't give a lot of directly comparable examples. Hangouts, for example, might not be getting a lot of development love right now with Allo and Duo being prepared for launch.

<comment><USER15> Hangouts isn't a good example to pick apart. The iOS app usually gets updates sooner than Android; it's not just a recent thing. Wifi calling, voice messages, redesigns all came first to iOS and then later (or never) came to Android.

</comment></comment><comment><USER16> Them and everyone else :)

</comment><comment><USER17> Is anyone surprised? Google tends to release some products/services in 'beta' mode and some of them tend to get abandoned or go on life support before having the plug pulled. Having said that, a lot of their offerings have an immense amount of polish and I'm grateful to be using them.</comment>


Fisher-Price Recalls Rock 'N Play Sleeper Linked to Infant Deaths - <AUTHOR> https://www.nytimes.com/2019/04/12/business/fisher-price-rock-n-play-recall.html <comment><USER2> I respect that they recalled it amid the pressure, but I feel for all the families, including mine, who would be SOL without the rock n play. It was the only thing that worked until 4 months.

I also really feel for the families who lost their babies this way. What an unfathomable horror.

<comment><USER3> My newborn was laying in one when I read the story. It was a very useful product, but I can't imagine losing my baby.

I'll have to research a safe alternative.

<comment><USER4> At the risk of being "that contrarian guy", I'm going to say it: this danger here is overblown. And yes, I used a Rock 'n Play for my firstborn and I plan to use it for the one on the way. The reason these children died is because the parents were putting them in Rock 'n Play after the point at which the children could roll over by themselves, which F-P explicitly said NOT TO DO.

It's a great product if you use it the way you're supposed to...

<comment><USER5> The initial warning last week said this was due to infants over 3 months who were capable of rolling and not using the harness. They also said only 10 deaths.

Consumer Reports did an investigation and discovered 32 deaths, including some where the infant was less than 3 months old and died without rolling over.

> _There is, for example, the mother in Hidalgo County, Texas, who placed her > 2-month old daughter on her back for a night's sleep on Oct. 19, 2013, > according to a lawsuit filed by the family against Fisher-Price. At 4 a.m., > when the mother checked, all was well, but by 7 a.m., the baby had stopped > breathing. Her head was tilted to the side with her chin on her shoulder, > compressing her airway. She was pronounced dead at the scene from positional > asphyxia, or an inability to breathe caused by her position._

> _The most recent deaths CR found occurred in spring 2018—one involving a > 1-month-old girl in Knoxville, Tenn., and the other a 9-day-old boy in > Copperas Cove, Texas._

There's another where a 7-week-old nearly died with their grandmother in the room, but thankfully she noticed the kid turning blue and lifeless and got him breathing again in time.

At this point I had to stop reading the article, it was upsetting me too much, but you can keep reading if you want to: [https://www.consumerreports.org/recalls/fisher-price- rock-n-...](https://www.consumerreports.org/recalls/fisher-price-rock-n-play- sleeper-should-be-recalled-consumer-reports-says/)

</comment></comment></comment></comment><comment><USER6> The only way my three kids would sleep at night was in one of these. Probably acid reflux, but it's a bummer these are getting recalled. I don't really understand how a child could suffocate in a rock and play any more so than in a traditional crib.

<comment><USER7> In addition to rolling over and suffocating, young babies with weak neck muscles died through positional asphyxia. Their heads tilted to one side and closed off the airways as they slept. It's the same reason infants aren't supposed to sleep in car seats outside of the car- the additional risk is worth it while driving, but not while stationary.

<comment><USER8> are neck braces ever used then?

<comment><USER7> I've never seen one. The best workaround is the SNOO, a 'smart' bassinet that is flat, rocks the baby, and is certified as a safe sleep surface. Unfortunately it costs upward of a thousand dollars while the Rock N' Play only costs $40.

</comment></comment></comment></comment><comment><USER9> Tragedy that this has happened. That being said, I'm not sending mine back. I've had it for 5 years since our first was born and my third uses it regularly now.

The babies don't sleep in it during the night. I buckle them in and I use my foot to help soothe them to sleep next to me while I work at my desk. If they sleep in it, I'm awake and alert and with them.

<comment><USER10> "The babies don't sleep in it during the night."

Yeah I get a feeling people were using these to kind of get out of soothing the baby at night. People were putting their baby in it and like walking away or going back to bed.

The Snoo I think is what most people want, but it's pretty expensive. But you can put the baby down, restrain them properly and then walk away or go to bed.

<comment><USER11> > _get out of soothing the baby at night_

I don't think you meant it this way, but just a note: it's not selfish for parents to prioritize getting some sleep for themselves at night. It is not good (or safe) for anyone if all the care providers are too sleep deprived to function.

<comment><USER12> Cosleeping solves both problems. A sober adult will not roll over onto the baby and a mother can sleep through even feeds. Around month three of our first child my wife commented that it was amazing our daughter was sleeping through the night without feeding. But she's just fuss a little and my wife would roll over and feed her on demand without waking up. It was so easy for both of us.

<comment><USER13> Co-sleeping is basically at the very top of the list of things "they" say YOU SHOULD NEVER EVER DO, OR YOU ARE A TERRIBLE PARENT. So I don't think its fair to recommend it as an alternative to pretty much any other sleep contraption.

</comment></comment></comment></comment></comment><comment><USER14> Lots of (surprisingly angry sounding) people in this thread blaming sleep deprived parents for not reading the manual of something that Should Just Work.

Comparing the risk to driving a baby around in a car is a fallacy.

The product is badly designed: once the baby can turn over there is a risk of suffocation _and the product does not allow for that_ (but it should).

A better comparison is to compare this product to the same product without the design faults, be that mesh fabric or whatever.

<comment><USER7> The problem is actually worse than that: even if you buckle your baby in it's still unsafe for unmonitored sleeping as the baby's airway can compress due to the incline. Using the product as the picture and text on the box depicts (sleeping next to Mom as she sleeps in bed, great for 'all-night' sleep) risks death. The initial CSPC statement and the company's response all (deliberately?) ignore that issue and those deaths.

The American Academy of Pediatrics is clear: the only safe way to sleep is on a baby's back, with no padding and on a flat surface. This product was never certified for safe sleep; Fisher-Price calls it a 'sleeper' instead of a regulated term like bassinet or crib to get around this fact.

<comment><USER15> Exactly. The CEOs should be charged with murder and the company sued into extinction. There is clear intent to mislead new parents into thinking this is safe.

</comment></comment></comment><comment><USER16> It's really important to read the article:

Mattel said in a statement on Friday that it stood by the safety of its products but agreed to the voluntary recall "due to reported incidents in which the product was used contrary to the safety warnings and instructions."

People would put stuff in the crib with the baby, padding, leave them unattended, etc. The product isn't at fault, it's the parents who are too stupid to read/follow directions.

<comment><USER17> Proper safety engineering accounts for human factors. Blaming the parents is improper.

Safety-critical fields like aviation assume that trained, certified pilots are fallible and design their systems to be resilient against human error. This is a product design to be sold to and used by not just laypeople, but laypeople who have probably only gotten four hours of sleep in the last four weeks.

<comment><USER18> How do you engineer away the ability to put blankets in a rocker, or crib for that matter?

Aviation tackles a lot of this with rigorous checklists, drilling, and constant ongoing training. They don't just design the plane to be impossible to fly wrong.

<comment><USER19> Engineering the rocker/crib out of existence is a valid solution if it's prone to misuse and that's what they did.

</comment></comment></comment></comment><comment><USER20> Whats a safer alternative to these things?

<comment><USER13> Following a strict list of guidelines that ensure the infant is in the most uncomfortable position imaginable, making absolutely certain that they are physically incapable of falling asleep _.

(_ without first screaming until 4am)

<comment><USER20> Haha that sounds about right. I meant to say is there a magical product that will set them to sleep for 8 hours straight without pooping, peeing and that will burp them occasionally?

<comment><USER13> Its called hired nighttime help. We did that with #2, after the experience of going through hell with #1. (Thankfully, both became quite easy to deal with after a few weeks. But at the beginning, its hard to see past the next 24 hours.)

</comment></comment></comment></comment><comment><USER21> Tangential point here, I found the range of prices for this amazing, $40 to $140. Why aren't shops who gouge people getting called out more often?

</comment><comment><USER22> We have 3 of these. Youngest is too small to roll over in it. But i guess we shouldnt risk it. Yikes.

</comment><comment><USER23> My partner and I are expecting our first child. She was building out a Wishlist on Amazon for things we'd need. Most of what was picked was not on Prime, was not sold by Amazon.com and had few (<10) reviews.

We had to have "the talk" about Amazon and how looking for "deals" on crap to buy the baby isn't smart. I wouldn't buy replacement windshield wipers for my car on Amazon, let alone a crib the baby would sleep in.

<comment><USER24> I believe you have been downvoted because your comment is irrelevant to the article. As far as I understand it, Rock 'n Play and similar are dangerous for infant death not because of their construction quality, but because the shape of the device is fundamentally unsafe.

<comment><USER25> You're correct, but given the problems that Amazon has with counterfeit goods and allowing the sale of uncleared products in regulated categories, OP does have a point.

<comment><USER26> an irrelevant point in this article thread because nobody talking about this fisher-price toy is a cheapskate.

everyone here already agrees, now lets talk about this issue at hand.</comment></comment></comment></comment>


Prismic.io - <AUTHOR> https://prismic.io/ <comment> aps-sids A better title to post maybe?</comment>


Ask HN: Besides programming, what's a realistic "work from home" job? - <AUTHOR>

I'm starting to think I should quit programming as a career and just do it as a hobby.
I don't like going out to work every day and am wondering what other type of work I could do from home. (It doesn't need to pay as well as programming because I spend very little and have no family to support.)
Any suggestions? <comment><USER2> \- writing. plenty of places still paying for content.

\- use software like tradestation or wealth-lab to build a workable trading system. trade from home.

\- background checks. with rise in VC investment is also new needs for doing cheap background checks.

\- penny auction arbitrage. there's a new startup in penny auctions every day. they start off unprofitable because not enough traffic. meaning, you can win cheap ipads for almost nothing and then sell on ebay.

\- project management. people still need websites done. You can outsource to india using scriptlance or elance and do the project management from home.

\- e-commerce. 1 idea: do a blog about living forever. when it starts to get traffic start selling a nutraceutical package on it.

\- photography. do weddings cheap. you have to leave home but dont have to work as many days.

I'll think of more if people like these ideas.

<comment><USER2> \- do a portal on class action lawsuits. almost everyone is applicable to win some class action (e.g. eat french fries from Mcdonalds 10 yrs ago? you won a class action. have an ipod in 2004, you won a class action, etc). High keyword spending there. No portals are good.

\- buy up popular domain names with the words misspelled (e.g. www.eatingdsorders.com, etc) - then do appropriate content (scrape sites) and google ads. Put together a portfolio of these names for cheap and sell to Demand Media

\- Write e-books. "100 Ways to Lose Weight". "40 stocks that can Double this year". Use simple google ads to sell them. Write 10 books / mo to make decent living and one might be a breakout. Traditional publishing dead. Get your friends to write e-books. You'll market, they write, split 50-50.

\- Therapists charge over $150-200 /hr. Charge $10 / hr and offer to do therapy over skype.

More coming.

</comment></comment><comment><USER3> Build relationships with companies that don't mind working with remote consultants or employees. Writing was mentioned by jaltucher and is a great place to start. If money isn't a huge issue, you could write squidoo lenses or web pages full time adding your own ads. I wrote a few dozen lenses for squidoo in 2008 early 2009 and they generated a steady $40-60 a month. Take that concept and push it to a few hundred or thousand lenses or focused sites.

</comment><comment><USER4> Why do you want to quit programming? Are you tired of sitting in front of a computer all day? or do you just dislike your current job?

I suggest answering these questions before considering any "work from home" opportunities. If it's just a matter of your current job, why not look for another employer.

</comment><comment><USER5> Day trading, and poker playing. Both require you to be of a type of person that makes one a good entrepreneur - willing to put in long hours and withstand a lot of pain.

</comment><comment><USER6> Translation.

<comment><AUTHOR> A friend of mine tried it and gave me the impression that, because you are competing with a worldwide remote workforce for work that does not require an on-site presence, translation work is extremely hard to come by, unless you have exceptional language skills.

<comment><USER7> Exceptional language skills or specific domain knowledge. For many languages, it is _incredibly_ difficult to find skilled translators with sufficient knowledge to make sense of technical, legal and medical documents.</comment></comment></comment>


Initialize TensorFlow Variables That Depend on Other TensorFlow Variables - <AUTHOR> https://www.aiworkbox.com/lessons/initialize-tensorflow-variables-that-depend-on-other-tensorflow-variables <comment><AUTHOR> Hi Friends- so I made this video tutorial because I ran into this issue a couple of days ago and just couldn't figure it out. Because TensorFlow does global variable initialization in a non-deterministic way sometimes the program would work just fine. Otherwise, the thing would fall over and have errors all over the place. I couldn't figure it out. Finally after looking through some GitHub issues, I realized that I was defining some variables that were using other variables. So when I ran sess.run(tf.global_variables_initializer()) every so often it would try to initialize some variables that depended on other variables already being initialized.</comment>


Intel's Long Awaited Return to the Memory Business - <AUTHOR> http://www.realworldtech.com/intel-dram/

<comment><USER2> For comparison purposes, Intel Itanium 9500 series Poulson-class processors have ~40 MB of on-chip cache, split among the L1 I&D, L2 and L3 caches.

<comment><USER3> But that's all SRAM, no? With about 10x the bandwidth.

<comment><USER4> Yes all SRAM

</comment></comment></comment><comment><USER5> The link will not load.

This article is about the same thing, presumably:

[http://www.anandtech.com/show/6911/intels-return-to-the- dram...](http://www.anandtech.com/show/6911/intels-return-to-the-dram- business-haswell-gt3e-to-integrate-128mb-edram)

<comment><USER4> The link takes over a minute to load, but it does load.

They must be serving this from a Raspberry Pi.

<comment><USER6> We had some configuration problems with apache, it should be quite readable now : )

</comment></comment></comment><comment><USER7> Isn't it the wrong direction to go? With the price of memory chips about $1 per 265Mbyte, and technologies of integrating multiple chips with tons of connections and speed(2.5D and 3D integration) closing by, what's the point in offering 128MB at a price hike of $50 ?

<comment><USER8> On die cache is orders of magnitude faster than regular ram. I have always thought that more cache would be a sensible addition when a process shrink give more available real estate.

<comment><USER9> Sure but that's static RAM. DRAM has 50+ ns of latency no matter how close you put it to the chip.

What they _can_ do though is achieve more aggregate bandwidth without increasing package pin count. Perhaps this explains why Intel was willing to allow Ivy Bridge to have only half the memory bandwidth of the previous Sandy Bridge: just not that many (non-server) systems were ending up with the four DIMMs required for full bandwidth.

So now they're integrating it into the package itself.

<comment><USER10> > DRAM has 50+ ns of latency no matter how close you put it to the chip.

This is not some fundamental law; it's entirely dependent on bitline and wordline capacitance (array size). For external DRAM chips, huge arrays make sense, and you end up with tens of ns of latency. In an eDRAM cache scenario, you use much smaller arrays, and in the case of the POWER7 L3, latency is more like 6ns (for row hits, of course).

<comment><USER9> It seems to me (you may know more about this than I do) that one can design a memory system to make latency for sequential addresses accesses arbitrarily small and this is mostly how (G)DDR(n) have improved overall performance. But random (row miss) accesses don't seem to have improved much.

From early 1980's to early 2000's, DRAM latency went from 150 to 50 ns and has stayed around there since. That's 1-2 doublings of performance in that parameter in the last 30 years, compared to who-knows how many in transistor size and speed.

Still, Intel knows what they're doing and I can see a place for (yet another) spot in the memory hierarchy before the CPU resort to off-package DRAM.

<comment><USER10> Yeah, given a predictable access pattern, latency can be completely hidden by prefetching. For an unpredictable access pattern, there's a physically imposed lower bound on random access latency, roughly proportional to the square root of the number of bits stored.

There's a huge tradeoff space between latency, bandwidth, capacity, and cost, and market forces have forced a convergence around 2 design points, colloquially DDR and GDDR. For yield reasons, die area (cost) has been mostly fixed for a long time. Successive generations of DDR spend the dividends of Moore's Law primarily on extra capacity, then on a bit of additional bandwidth when possible. Successive of generations of GDDR prioritize bandwidth, primarily by dedicating tons of area to high-speed single-ended I/Os.

These two design points make sense for their most common use cases. In traditional disk-based systems, avoiding hitting the disk is more important than absolute DRAM latency, so increasing capacity is your best bet. On GPUs, you need enough bandwidth to feed a quickly growing number of functional units on the chip, and at least for graphics, the access pattern can be made to be extremely predictable, so latency is not as important there.

The advent of faster-than-HDD persistent storage (SSDs) and the desire to run more general purpose workloads on highly parallel machines like GPUs points to a need for a third DRAM design point.

<comment><USER11> There is RLDRAM, but I've heard that it's expensive.

<comment><USER10> Yeah, there are a few specialized parts for networking, telecom equipment, defense, and other less cost-sensitive applications, but DDR and, to a lesser extent, GDDR dominate the market and enjoy much greater economies of scale.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> No matter how tightly integrated it is into the package, I'm skeptical that Intel integrated graphics with 128MB of DRAM is going to replace an Nvidia GT 650M with 1-2 GB of GDDR5.

<comment><USER12> Intel started out targeting the low end discrete graphics solutions, now maybe they re just moving their way up the food chain.

I'm actually more excited that the CPU has access to this cache too.</comment></comment>


Purpose of Life - <AUTHOR> What is the purpose of life? What do you think? Whats the point of suffering even though it is going to be a waste eventually? <comment><USER2> Instead of answering, I am more concerned about the state of mind that produced that thought. Are you in a healthy place right now?

<comment><AUTHOR> Should i mourn about my miseries or a simple no ? Which makes more sense?

<comment><USER2> I know it seems cliché but things do get better with time. Its going to get better

<comment><AUTHOR> Just because some one says it does not mean it is going to be okay . I had to leave my home where i was lived for more than 10 years . No going back. Dad had to move out from us due to issues. No going back to anything. He cant come back. Isolated. alone. far away. had to leave major household items. When would it get beter?</comment></comment></comment></comment>