realrocker

Location: Bangalore

Remote: No

Willing to relocate: Yes

Technologies: Android Expert: Mostly AOSP internals(frameworks, systems, HAL, BSP, build scripts). Also dabbled in Application Development, Mobile backend Services.(github.com/adnaan)

Resume: On request.

Email: badr dot adnaan at gmail dot com

Middleware person. Worked on a tablet, a smart watch, couple of android apps, few web servers in Java, C, Python, Go. -----

I guess it's about doing the best you can within your comfortable time frame. For e.g last week, a colleague of mine was trying to execute a statically compiled program like an executable i.e. ./myprogram.go and then raised hell over how bad Go is and we should rewrite everything in Python. That's the kind of attitude I am talking about.

True there are many who take a job to survive. But I think you are confusing "passion" with motivation. A motivated team member would not sit back while her teammates are passionate about the work.

As a low level android middleware guy with little knowledge of css in practice, I found this guide: http://www.basscss.com/docs/guides/basics/ very effective. Especially the recommended order of css commands made a lot of sense to me: http://www.basscss.com/docs/guides/basics/#order .

Join back the medium-large engineering job if you could. Cancer treatments are getting better everyday. But priority one is buying yourself as much head room as possible both in terms of money and time.

I really want Firefox OS to be a success. After working in AOSP firmware for last 5 years and dealing with vendor walled gardens, I wish there was a truly usable open source phone.

I think being always right in this context means being less open to consensus and taking up more responsibility of execution. This could be very crucial in a fight or flight situation. Most of the time this is a very natural response to adverse situations. Like I said such a response has a very short shelf life. But being persistently in the same state long after the crunch time has passed is definitely not ok.

Notice how it was OK for him to be mean while Facebook was growing up it's infrastructure. Being right unfortunately is a necessary evil for the first wave in any project. In the nascent stages a project often needs firm almost machine like guidance. As the project matures the sense of stability trickles down organically to it's members. Some make the transition well while others dont. Often the best of our champions don't make the cut. The author has rightly pointed out the importance of Kindness, but that's not enough. The leadership should also be kind and help these mean incumbents make the transition.

What good luck I have! I have been fiddling with a procedurally generated 3d world and there are all these great articles about procedural art up on HN. Anyone know of an example project for a procedural 3d world?

Location: Bangalore

Remote: Yes

Willing to relocate: Yes

Technologies: Android Expert: Mostly AOSP internals(frameworks, systems, HAL, BSP, build scripts). Also dabbled in Application Development, Mobile backend Services.(github.com/adnaan)

Resume: On request.

Email: badr dot adnaan at gmail dot com

Middleware person. Worked on a tablet, a smart watch, couple of android apps, few web servers in Java, C, Python, Go. -----

What about the legal implications of this? If a vehicle is in a collision and there is indication that the software might be responsible, who takes the blame? This is going to get really bad.

Location: Bangalore

Remote: Yes

Willing to relocate: Yes

Technologies: Android Expert: Mostly AOSP internals(frameworks, systems, HAL, BSP, build scripts). Also dabbled in Application Development, Mobile backend Services.(github.com/adnaan)

Resume: On request.

Email: badr dot adnaan at gmail dot com

Middleware person. Worked on a tablet, a smart watch, couple of android apps, few web servers in Java, C, Python, Go.

$make -j16 showcommands > build.log 2>&1 | less +F

ctrl+c...

<shit its not working>

ctrl+c * 1e9 impatiently

...

build stopped

oops

"you could allocate huge amounts of memory compared to Java without any issues". No sir. It still comes under the process memory account. It works in practice because coincidentally other processes were not using that memory.

Well allocating on ashmen does reduce the UI lag since its just a memory pool and espaces GC reprimand but it's definitely not safe. Such operations are better handled at Gralloc/HWComposer Layer where you have a better handle on what's going on. Someone's gotta unlock that surface!

Hey. Quote,

"Our breakthrough came when we realized we didn't have to do that. If we called lockPixels without a matching unlockPixels, we created an image that lived safely off the Java heap and yet never slowed down the UI thread. A few lines of C++ code, and we were home free."

That doesn't sound complete. It's off the Java heap, true but doesn't mean it's either safe or won't slow down the UI or is even home free. Allocation in ashmem will still count towards the PSS[1] of the app. The image data won't be unpinned right until it throws an OutofMemory exception. And if you have handled the exception, the UI thread will wait around for the unpin/unlock of data. This would be ok if you could make an educated guess of how much ashmem can be allocated to your app. You can't make that guess easily as it depends a lot on OEM implementation of Gralloc/HWComposer and the GPU. But since you are Facebook, :), you can probably test this on all device/gpu variants. And when you do please publish the results. And while you are doing that, please test this too: http://developer.android.com/reference/android/os/MemoryFile...

[1]https://developer.android.com/tools/debugging/debugging-memo...

Thoughts?

Edit: Incorrect link

I bet I can put together dozens of people who think OOP and MVC are bad programming paradigms, another dozen who can make war on the quantum of documentation. We already know the solution to this problem: We need to hire people who have the skills to hire people and willinglines to do it too. Just being a senior doesn't cut it. Too costly I guess but is it costlier than making bad hires?

IMO successful startups are the one's where founders had the skill to identify and hire the right talent. What I don't understand is why big companies are not creating a separate division of engineers with primary task of hiring? Is it because that if such a division existed the people there would eventually lose the skills being cut off from mainstream engineering tasks? I am not sure. But it seems to me that this can be solved by looking at hiring task as an engineering task. What's wrong in seeing hiring engineers as another piece of code which needs to be carefully thought and polished?

Hackathon is a side-effect of a wider change in modern software development. We seem to have successfully commoditized a portion of it. This portion called "apps" is mostly a cosmetic rearrangement of underlying components. Flush funding and the apparent status such work provides is hard to ignore. I mean how am I supposed to say no to a 10k prize money for 10-12 hours of work?

Whenever a product is commoditised, the brushes hide and the hammers come out. Imagine how the elite calligraphers of the 15th century felt when their beautiful noble art form was replaced by a block of wood. And the disgust they would have felt of seeing books in the hands of common folk instead of the Kings. IMO I think it's alright since we are not sure yet whether the hammers cannot change the world. They yet might.

Or inject them with nano-fibre(?) Use them as a container.

Data. We can use them to store data. Not your average cat picture storage but maybe DNA data of plant seeds and such.

Sure. I think it's important to empathise with people. Especially in a professional setup. But how do you empathise with the lazy ones who would come to a meeting unprepared, hoping to get a quick tutorial on the subject on the go. Or the condescenders who would assume their expertise on a subject renders all other opinions invalid. In those cases empathy is actually cruel to the remaining who do deserve it. Empathy like every other human emotion isn't really universal.

I think most freelancers do this. I have done it my time.

Bravo. AOSP hacker of 4 years and I have been meaning to write something like this for a while but never got around to it. Would love to contribute. Please add a few guidelines to the README.

For some people the sense of fellowship is more important than self-being. If you are one of those, well, it's going to be tough for you. Anyhow I would recommend:

1. Take little walks during work. 2. You also need a sound board, a colleague whom you can trust to validate your work and thoughts, because the one thing you can't afford is to redo things. Just trust this random stranger from the internet on this one. 3. Try to get a fix on the date when you can take a time off.Knowing that takes of the edge off a bit.

I struggled with similar problems. So I have three fixed buckets of time now. First bucket is the job. Second bucket is for one side project. Third bucket is for anything under the sun: Linux kernel, Reactjs, Rust, Android, ML... I call the third bucket as the "fish bucket".

Really like the story-telling style of the article. Was wondering where could I find a compilation of similar "programming tales"? Apart from http://www.folklore.org/ of course.

Location: Bangalore

Remote: Yes

Willing to relocate: Yes

Technologies: Android Expert: Mostly AOSP internals(frameworks, systems, HAL, BSP, build scripts). Also dabbled in Application Development, Mobile backend Services.(github.com/adnaan)

Resume: On request.

Email: badr dot adnaan at gmail dot com

Middleware person. Worked on a tablet, a smart watch, couple of android apps, few web servers in Java, C, Python, Go. (Not actively looking but you never know. Curious to find out whether this thread works)

Since many of these bugs are also simultaneously raised by OEM's they are closed internally without feedback. And feedback to what bug, they are so many for the same! Also lot of them are feature enhancements and are really opinionated actually to work on. It could be better but it's not that bad. You won't believe the hoops you gotta jump to get anything done. Too many stakeholders in AOSP!(which has both pros and cons). I work on the AOSP for an OEM.

"Culture fit" is quite stupid. A fair amount of conflict is key to fiery technical debates and keeping out the complacency. Imagine if the parliament worked like that. Hire people who would own a responsibility and have the ability to execute it too. Everything else needs constant gardening.

Only few businesses want a well-crafted software. Today's startups are endeavors of treasure hunts. You build a ship just good enough to hit the island. If it doesn't work out(which in all probability it won't) you dump the ship. If it does, you still dump the ship. There is a element of expected failure in the current enterprise of writing software which calls for and pushes people to knowingly write bad fast software. As the author says it will be faster to write slowly if the goal is to write good software. But the goal is rarely that.