6 Rules To Live By When You Work In An Office But Have Remote Team Members

http://blog.trello.com/6-mistakes-when-you-work-in-office-but-have-remote-team-members

RealWorld TodoMVC - Medium clone using different frontends and backends

https://github.com/gothinkster/realworld/blob/master/README.md

Also have to checkout - http://todobackend.com/

Spoilers: they have you make a blog.

A blog. One of the most simple inventions that never would have existed without the web itself. And it takes full advantage of the web too: querying & persisting data to a database, an authentication system, session management, full CRUD for resources—and now these days social blogging platforms (like the site you’re reading this on) have also perfected relational features like following, liking, and commenting. A blogging site is the perfect example of a simple yet robust web application.

d3.exprrss

https://medium.com/@mbostock/a-better-way-to-code-2b1d2876a3a0

'General' Rules/Advice/Reminders to developers like myself

1) Assumptions
Make no assumptions.
Try to confirm in any way possible - e.g read documentation, ask someone, look more closely at the codebase, google, etc. etc.

2) Abstractions
Learn to view any system as consisting of layers of Abstractions.
Thumb-rule: To fix an issue - Work at the highest level of Abstraction as possible.
Knowledge about all levels of Abstraction is desired, but, among all the levels of Abstraction where solutions are possible, fixing a bug should be done at the outermost level of Abstraction.

E.g. Bootstrap widgets use jquery internally. Use the functions that Boostrap provides when working with Bootstrap widgets. When everything that Bootstrap provides proves to be insufficient, then use jquery.

3) Developer Testing
Test end-to-end, the feature that you are touching.
And that is the bare minimum.
In addition to the above, we have to think about all the other areas that could get affected by our changes.

E.g. If you are touching Step 2 in a feature that has 5 steps, we have to test all the 5 steps, and not just Step 2.

4) A good developer is a Power User.
We have to know about the things we are developing for.
We have to constantly be using what the users are using or will be using.

E.g. Unless you are a frequent user of Social Networking sites, you cannot be a good developer if you want to do some development related to Social Networking

5) 3 things to keep learning - programming languages/frameworks, company specific framework,  Domain
Knowledge of the various programming tools (e.g. Ruby/Rails) we will be using daily is the bare minimum.
Apart from the above, usually every company has some specific frameworks that they have built for themselves. We have to learn that too.
Once we have enough technology knowledge, we can start to contribute towards solving Business Problems (of all sizes). Solving Business Problems however needs Domain Knowledge too. So we have to try to learn that as well.

6) Courage to learn at your own pace
It is sometimes very disheartening when we struggle to learn something new.
During those times, it takes a great deal of courage to still continue, and not give up.
We have to remember that learning slowly is infinitely better than completely giving up.
Giving up temporarily is ok - recharge and try again.
This is very important because, as developers, we have to learn continuously.

7) Screw Office Politics & Discussions to improve Process
This final point is an opinion and not a general rule like the above 1-6 rules.

Process, People-Management are important to any company and some people do have to worry about such headaches.
If that is not your cup of tea, always be on your guard to not get into those things, because such things are a daily reality for any company.

Seemingly-Harmless-Gossip is prevalent in every company and can have serious effects on people's careers if indulged in too much.

Office Gossip - Not OK;  Other Gossip - OK
Process Discussions - Not OK; Technology Discussions - OK

Motivation vs Discipline

http://www.wisdomination.com/screw-motivation-what-you-need-is-discipline/

"Screw motivation, what you need is discipline."

Part 2 - Practical Discipline - http://www.wisdomination.com/practical-discipline/

Automated Testing: EndTest

Codeless Automated Testing:
http://endtest.io/
Free to evaluate - http://endtest.io/pricing

Intro to React

https://github.com/ericvicenti/intro-to-react

Subtime Text related: Useful plugins

The following have been invaluable plugins to me:

Git Gutter
MoveTab

Data Structure and Algorithms

https://techiedelight.quora.com/500-Data-structures-and-algorithms-interview-questions-and-their-solutions

Learn ES2015

https://babeljs.io/learn-es2015/

jquery: dropdown

http://stackoverflow.com/questions/2780566/get-selected-value-of-a-dropdowns-item-using-jquery

For single select dom elements, to get the currently selected value:

$('#dropDownId').val();

To get the currently selected text:

$('#dropDownId :selected').text();

UXDD - UX Driven Design

https://msdn.microsoft.com/en-us/magazine/mt619988.aspx
https://app.pluralsight.com/library/courses/ux-driven-software-design/table-of-contents

Excerpts:

"puts UX at the foundation of the entire design process."

"From a functional perspective, you can successfully build a working system regardless of whether you start the design effort from the bottom (say, from the persistence model) or the top (say, from presentation layer and view model). From a UX perspective, you can only be successful if you start designing from presentation and view models and build everything else, including the back-end stack, from there."

 "I learned from UX experts that requirements are better actively generated through evidence-based discussion than passively infer­red via interviews"

"Very few tasks are entirely accomplished through a single screen that you can summarize effectively to a wireframe. Just looking into the wireframe of a screen may not be enough to spot possible bottle­necks of the process implementation. Concatenating screens in a storyboard is a much better idea. In this regard, the biggest challenge I see is finding the tools to build storyboards."

 "... simply outsourcing the presentation layer to a team of UX experts isn’t enough. The presentation layer today is the most important part of a system and must result from the combined effort of solution architects, UX architects and customers. This must be the first step and ideally you move on only when the customer signs off on the presentation."

Figure 2 Tools for Quick and Effective UI Prototyping

Tool	URL
Axure	axure.com
Balsamiq	balsamiq.com
Indigo Studio	infragistics.com/products/indigo-studio
JustInMind	justinmind.com
UXPin	uxpin.com

Not sure why https://www.invisionapp.com/ was not mentioned in his article above.
It is being used by designers in our company and it seems to be pretty good.

The Churn - No point discussing/fighting it

From what I have seen, companies just seem to want/require/need Change from time to time.

They end up restructuring their team(s). 'Reorg' is an often heard term.
Or they want their technology stack to change.
Or they want to bring in new Processes.
Or they bring in new people, fire some old ones, etc. etc. etc.

Depending on luck, individuals like me can get caught up in the politics of it or not.

Questions like "Are these changes required? Are they fair/correct?" come to mind and discussions inevitably take place between colleagues and we all feel miserable for a long period of time.

I have not been able to describe this phenomenon previously, but after hearing about 'The Churn' in an episode in The Expanse, I finally got convinced that this is it.

Excerpt from blog https://medium.com/anomalous-engineering/welcome-to-the-churn-5c201b3e9759 explaining what 'The Churn' is:

"When the jungle tears itself down and builds itself into something new."
...
"Some things are so fundamental that you can only survive them, or not"
...
"Until the Churn settles into whatever the fuck the New Normal becomes, we could be the looters, or the volunteers stopping them, or victims, or just bystanders"

And to maximize our chances of survival, the below blog suggests we should make ourselves 'deserving' of survival.

The Churn is inevitable, so there is no point in wasting time & energy in discussing it. It's better to use that time & energy to become more 'deserving' of survival.

As programmers, team-members, how can we become more 'deserving' of survival?

2 things come to mind:
1) by continuously putting in effort to improve our skills
2) by continuously putting in effort to be nice/fair to our colleagues

Next time, I am tempted to discuss 'stuff' about The Churn, I will try to remind myself - "It's The Churn man... There is no point in discussing/fighting it"

(The Churn - https://medium.com/anomalous-engineering/welcome-to-the-churn-5c201b3e9759)

H-1B: Memo clarifying USCIS practice says employers must show the job is a specialty occupation

H-1B Visas for Computer Programmers May Be Harder to Come By

Memo clarifying USCIS practice says employers must show the job is a specialty occupation

https://www.shrm.org/resourcesandtools/hr-topics/talent-acquisition/pages/computer-programmers-may-need-to-fight-to-get-h-1b-visas-as-usual.aspx

GlimmerJS

https://hackernoon.com/why-im-excited-about-glimmerjs-3631bd0c95c4