Being in Software Development workforce for nearly 20 years, and in Android Development for 5 years, I observed that different developers does have different attributes. Some are stronger than the others in some aspect.

Do check out which type you are in, or your fellow team member is…

I divide them into 3 categories i.e. Technology, Process and Product. From there, I’ll share each of the attribute, using Android development terminology as example for some. These attributes should applies to other software developers too other than Android.


Developer is a profession of learning and progressing. Stagnation would be fatal. Technology evolution getting shorter and shorter, hence the at least one of following attributes are essential to ensure one to continue to be in this profession.


Google I/O developer conference happens every year. As Android developer, if you get excited and always wanted to be the first to touch on what’s announce (or for some, even before it is announced), you definitely have this attribute. As of today, you perhaps has gone beyond Android development, and have touch on some AI related stuff (e.g. tensorflow) and/or AR/VR in someway. You don’t mind using Android Studio canary version while it is still being developed. You might be already using coroutine of Kotlin.

If you haven’t use Architecture Component (which was announced last year) and have not touch Kotlin (not referring to loving it), I think you might not score yourselves good here.


You know MVVM, MVC and MVP and more, and able to tell the differences between them clearly and precisely. Always think of the future of what-if e.g. what if the data-source is no longer using JSON. Abstracting some logic away excites you, though it might not needed now. You have some strong believe in some approach (e.g. Functional is must better then OOP or vice versa) and evolve from case to case of usage. You have your opinion on the latest Architecture Component proposed by Google.

If you don’t get upset when you see some Android Framework object(e.g. context) resides in logic piece of class, or see your activity or fragment having some complex logic seems okay with you, then it’s hard to say you cares here. You would rather stay with one pattern or approach, so you could just play safe, instead of need to rethink of suitability and refactor code to make a code architecture nicer.


You like something that looks really elegant. e.g. prefer using RxJava as it looks much more elegant than normal imperative approach. You like Functional Programming as not just because it simplifies and make things cleaner, but also it is so cool. You would want to understand very single bit of it, and perhaps have dive into Android framework source code, to know how things are done. You like optimized code concisely e.g. you prefer repeat(x) { doSomething() } over for (i in 1..x) { doSomething() }

If you hasn’t understand how Dagger 2 works, (not referring to copy-&-paste using it), I don’t think you are very academical. You prefer using simple library to achieve location detection than writing one yourselves.


Across the 3 categories, these areas perhaps is least love by typical developer, in doing these themselves. They understand their important for future sustainability, and would really love someone to aid in these areas or think of shortcuts to make them better (hence the introduction of Agile Development, which simplifies many processes 😉). Nonetheless, as developer, these attributes helps for one career development.


To start a card (story), you want every single detail documented well. You would go the extra steps to learn what the acceptance criteria is before starting a project. In order to ensure QA could test your work, you’ll record down every single scenario possible for QA to follow. In your code, comments is something you don’t mind adding in. You prefer new (cards) stories when you found a new area to work on spawning from your existing work.

If you prefer coding than documenting, and don’t mind no documentation, then you are you are not a scriber. Your belief is code is the best documentation, but for the code you wrote, you might not understand after 3 months.


Naming variable, functions etc are most particular for you. If possible you would prefer functions like fun enableClick() and fun disableClick() than a single fun enableClick(enable: Boolean). An extra space or extra lines in the code irritates you. In your test function, you probably not name it like fun testSomething(), but instead fun `when set a then b should run`(). You probably have introduce checkStyle or detetk for your build.

If you still use manager or factory in your class name, and uses i or x for your variable name, you are probably not a Linguist. You don’t even bother to press Alt-Command-L or Ctrl-Option-O in IntelliJ for proper formatting before you commit your code.


To you, if there is no test for a code, it is not functioning. You know what is UiAutomator, Expresso well aside from Junit. You don’t mind going the extra miles of creating end-to-end test and uses Amazon or Firebase test farm, so that you could sleep better at night. You might also consider make your private function public if that is needed to make it testable. Using Interface is preferred, as you could mock them easier for testing.

If you didn’t bother writing test for your logic code when check in for Peer Review, and think the QA personnel should be able to find issue if it is there, then you are not a tester at heart. Even if you write a test, you don’t see the need to make them fail to ensure the test is working.


Build time, automation, reduce manual effort is what you really cares. You are a master of a few script languages, and Groovy is something under your sleeve. Docker is no stranger to you, and you probably have a good set of images that have all the needed libraries set properly. You hate brittle tests, and sometimes question the need of running extensive test throughout. Peer Review process and GitFlow is well controlled in the process so mistake of merging is not possible. iOS and Android development should be as consistent as possible, so we could share the process.

If you don’t even realize how much time it takes to make your build to be available to QA to have that build, then this is not your area. You don’t mind doing things manually tens of time, instead of spending time automating it.


While at times this is neglected by some developer, it’s arguably this is the most important category to ensure the success of everything. Such acumen is essential, as customer concern would makes or breaks the project. These attributes would help focus of what matters. If one looking to grow into manager of a team, such attributes should not lack.


A single pixel different would concerns you. Animation is not meant to show off, but need to have meaningful transition and natural. Your are familiar with animator, cross fragments and activity transitions, and might have play around with Constraint Layout 2.0. You spends hours thinking on icons, colors, words, fonts etc. to be used. You would think, is this feature discoverable? Material Design is in your blood. Janky scrolling is hurting your eye. A card without a proper elevation will kill you.

You are not a designer developer, if you don’t feel any different when using a native Android vs. webView page. If a designer gives you a proposal, you will never review or question the design. Instead, first things come to mind is it technology feasibility. You’ll propose a tradeoff if technology is not feasible at first glance (without spiking it through first), even if the tradeoff means not-as-nice a design.

Quality Assurance

Crash is the last thing you want for the feature you develop. Your programming is very defensive. You think of a ways to send logs back for reports to be aware of the issue ahead. You’ll turn on StrictMode in Android to dig out any potential issue. You’ll run LeakCanary and if a memory dump is shown, you’ll hunt it down till it is resolved. You’ll never resort to using commitAllowingStateLoss() without understanding why.

If you code variable!! in Kotlin, and that doesn’t bother you, you are definitely not having QA in mind. Making an RXJava Subscription, you forget you need to dispose it. When you introduce a new Fragment or Activity, you don’t even test it with don’t keep activity to ensure state restoration works properly.

Business Man

To you, customer is number 1. You like agile methodology not because it makes process simpler, but because you could get your stakeholders inputs constantly. You don’t mind code and having tech debt card (story) to be done later, in order to ensure we ship things in a timely manner. You would rather code for what foreseeable need, than to abstracting the layer of code for an unknown future need. Analytic is very important to you, as well as customer feedback, to understand how it is used. You love A/B Testing, and don’t mind introduce toggle within the code, and role back when situation is not needed. No animation is fine if it get things done and user get to use it soon before competition does it. Business priorities come before anything.

If there’s two options of doing a feature, one is faster, the other is better, it’s no brainer for you to go for the better one, even though there’s customer pressure needing that feature, then you are not business minded. You hate tech debt would avoid it at all cost. Nice animation and cool feature is something to be shipped even though no one is likely to use it.


It would be almost impossible to have one single person owns all attributes, as some of these attributes do contradicts with the other. That’s the reason it would be great to have a team of different developer with different complimentary attributes. This would enable a healthy tension that provides a balanced discussion and consideration for each project.

While arguably, some of these attributes could be a trait of the actual profession in the group (e.g. a Project Manager playing the business man, and a QA Tester, plays as a tester role) instead of developer, it definitely helpful to have a developers having such attributes in the team, as that would then gives a more accurate assessment of what it takes to develop something (e.g. from a business point, or tester point of view), as they are the subject matter.

Also it is most important that we don’t demand that all developers having all these attributes, as some of it are shaped through personality temperament and some would only attainable through extensive experiences. So it’s okay for any developer to be lacking in some area, while being stronger in some other area.

Nonetheless, it is fair to propose area of development for one, to build one career as a more holistic developer.