Developers need to continue to learn to be competitive especially in computer science since new technology and tool sets are constantly being developed.  To help facilitate learning, there should be a culture of learning in the company. If everybody in the company is complacent in just using the same tools or not learn anything new, it does not encourage anybody to go on and learn new stuff.

Learning new ideas lead to try and drive technical changes. This might be simple in a  start up company but at older companies, departments and bureaucracy can lead to huge resistance on change. Not only do you have to try and convince your co workers and your boss. Your boss may have to convince your department, your department may need to convince even higher in the company in important issues. Sometimes order comes from higher-up and there is no way to change the opinion of that.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

Sometimes companies hire the wrong type of person for their position. It can be hard through phone interview to get a feel about a candidate. Sometimes a person that seems to be knowledgeable can have a bad work ethic or may no mesh with the company well. They might not even have the same goals as the company and may just use this opportunity as a stepping stone.

Hiring the wrong people can lead to bad morale. Struggling to get products out, leading to lower morale, leading to slower dev time. It is a downward spiral. Manager and developer conflict can also be a real issue as both sides can have conflicting interest on what is needed to be done.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

Finding a great developer can be a challenge. It can take a long time to find one that’s the right fit for a company. A person can be great at interacting with people but may not have the best coding abilities. A person can also be a coding genius but will mesh with the team leading to a lower productivity than the former prospect. It can be difficult to find the best match for a position especially when many times you need to train the new people to their tool sets.

When you first start out, interviewing feels more like “I don’t care, I just want a job”. As you get more experience, interviews become more about a 2 way process. They confirm your skills and your fit to their team. You ask question about their company and what they want to do. Even new, it is important to try and ask questions about the company.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

TDD and agile development is always talked about. Pair programming is always praised. However, sometimes those practices are just not feasible. Many times programmers will have multiple issues/projects they are working at once. Although you might have some time to collaborate with your co workers, chances are they are also busy and you are mostly asking questions instead of pair programming.

Extreme programming seems to work the best in some situations but not all. In extreme programming, the team self organizes around a problem then solves. However, there can be times where nobody wants to work on a mundane issues that can be critical to an operation. The manager then have to assign, and some projects may not work well under extreme programming.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

Saying no can be difficult in a professional setting especially if you are new and your boss wants something. Managers that haven’t really programmed will keep trying to push new features or push frivolous features that takes a long time. There were time in my work where managers were pushing for extra features that ended up being not used by the end of the product cycle. Problem with is, unless you have some experience, you probably can’t say no.

This ties into deadlines, saying no can be hard especially if you are new. However, many people expect you to run into issue when you first start up and it does not hurt to ask. It is better to be delayed than write bad codes that will run into issues in the future. Unless it is a crunch time, then you have to get it done.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

The author brings up some interesting point in which it takes more than a few developer to have the craftsman model to work. The entire company has to embrace it. It was interesting hearing him talking about how there would be developer swaps between different companies in order to see how another company operates and bring back information where it can help improve one’s own company. This might not be feasible in every situation as many times companies are competing against each other.

The author again tell us that in order to be a software craftsman, you have to be constantly learning. In order to want to constantly learn, of course you have to be passionate about programming. Practicing new problems and figured out how the problem is actually being solved instead of just trying to brute force solving it. Doing personal pet projects to constantly refine and improve old skillsets while also learning new ones.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

It is interesting to see how the author view seniority in programming. In most places, seniority comes with years of experience. One thing that is different in Computer Science than in other field is the constant evolving of the tech, language, framework, and tools. Having years of working in the field and eventually you may become obsolete if you don’t try and constantly learn new stuff. A person that is entry level might know more about the latest node.js technique than a senior developer.

However, seniority does not just mean how well you can program. Seniority can also mean you know how to communicate effectively, how you work well with team, how well you can lead other people. An entry level developer may have better coding skills than a senior developer but I doubt he has other experience that may be critical in a company.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

We ran into issues with our solution to the problem.

1. Our fix modifies the npm webpack which is in another github repo
2. It is a band aid solution since the weeks still shows as the pre set 2,4,6,8,16
3. We are unable to use Travis CLI since it is not the ng2-amrs repo

In the end, we contacted AMPATH team through Slack and figured out it was through their JSON schema. We contacted the admin who had control over the JSON schema over JIRA. The admin updated the weeks to show 24, and 36 on the dropdown. The issue was then fixed and close.

It just shows how important communication is. When you have a problem, you have to be proactive and ask question on what is going on.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

I think we figured out the issues for our JIRA ticket.

node_modules/ng2-openmrs-formentry/src/app/components/date-time-picker/date-time-picker.component.html

line 11: <li (click)=”weeksSelected(count)” *ngFor=”let count of weeks”><span> {{count}} Weeks</span></li>

This line is basically our dropdown, when clicked, it will basically iterate over the weeks list and display the count

node_modules/ng2-openmrs-formentry/src/app/components/date-time-picker/date-time-picker.components

line 19
export class DateTimePickerComponent implements OnInit, ControlValueAccessor {
@Input() modelValue: any;
@Input() showDate: boolean = true;
@Input() showTime: boolean = false;
@Input() showWeeks: boolean = false;
@Input() weeks: number[] = [2, 4, 6, 8, 16, 24];

Here is the weeks list, in the list it has 24 but it will only display up to 16 weeks.
There seems to be something funky going on with the weeks variable.

If we add another input for example:
@Input() testing: number[] = [2, 4, 6, 8, 16, 24, 36];

In the html, change weeks into testing

line 11: <li (click)=”weeksSelected(count)” *ngFor=”let count of testing”><span> {{count}} Weeks</span></li>

This will display 2 Weeks to 36 Weeks
——————————————-
1. Test this on your ng2-amrs and see if it’s the same
2. Mess around with the form submission to see if it’s stable
3. Try and figure out why weeks is basically pre set to [2,4,6,16] no matter what is put in there.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

This Sprint, we got everyone on board with AMPATH test2 server and checked out the code issue that was assigned on JIRA. It was interesting that we spent a huge amount of time trying to get standalone server to work and then it became useless as we transition to the test2 server.

We have an interesting issue on our JIRA issue in that we are unable to reproduce the error that was given to us. The JIRA issue was that a randomly typed location can be typed in and saved. When we tested with the test2 server, the location if randomly typed cannot be saved. I have commented on the JIRA ticket asking for clarification on this issue. Meanwhile, we are all just studying the code base for further understanding of the entire AMPATH system.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.