Really agree with you. Usually I tried to do some side projects/weekend projects if I want to try out something new. For example, when I learned PHP, I build a website with it. Later when I learned AngularJS, I build another website with it(https://pxlet.com). Now I am interested in VueJS, maybe I will start to build a new one with it. This really helps you understand something in deep.
Learn and act. Doing something real with what you learnt and you will grow while you are building it. Also keep refreshing yourself with the new technologies and trends.
You can follow http://www.pxlet.com if you don't want to get lost in all the different sources and it comes with bunch of other features. I check this one everyday now.
Hmm, another big challenge for continuous delivery is actually human factor. You need to have people who can work in continuous delivery mode. This factor is more critical than that of traditional software development based on my experience.
Excellent. So we can submit links there as well? Actually here is another one which collects HN data but presented in another manner(It uses AngularJS for quick modelling). http://www.pxlet.com/
As lots of people know that IBM gets 21 consecutive revenue decline and it's forced to cut down cost. But cutting down cost doesn't mean you should shift your development work to under qualified developers or programmers. This will further affect IBM's software quality and hurt its revenue. Why not putting the money hiring less but good developers. If you are a developer, you would find what that feels like to work with under qualified developers.
To be honest, have you heard about any impressive software product or solution from IBM in recent years? I would blame this to a short-visioned management team. Maybe its management team is thinking they could hire more below averaged developers with the same money of hiring one good developer in hoping that quantity can cover quality. In fact that's totally wrong in technology field.
Moreover, those talented technical people are escaping because they are not getting what they deserved. The management team is investing far less in technical talents than in so-called business. The end result is that the product quality will become worse and worse and customers would finally give them up.
While other companies are attracting talented IT people by all means, IBM is lost and it's driving them away.
A lot of assumptions and bias in the comment above. You are implying that more expensive means higher quality. Less expensive means lower quality. Both are not true.
The truth is, "opensource software and cloud" disrupted IBM's business model of selling proprietary software that runs on IBM hardware and selling services to maintain these.
Sorry, you misunderstood my point. My implication is that we should spent the money on the right people. For example, if we have budget of $10000, we can spend them hiring one/two good developers instead of hiring 4/5 below average developers.
Why? The company has reported declining revenues for 21 quarters -- more than five years -- is shedding tens of thousands of staff, doesn't generally pay high wages, has no market-leading products, and has a less sexy image than Apple, Amazon, Google, Facebook, Microsoft and practically every other significant IT company.
(I did say American developers, not Indian developers....)
Because talented engineers don't want to work on the typical things that get outsourced, such as maintenance of legacy applications, helpdesks, implementation of dull ERP projects and so on. Therefore on average the quality of programmer at an outsourcing company is lower than at a real product company, and this would be the same at any outsourcing company in any country. It just so happens that some locations are cheap enough to make hiring large numbers of low quality engineers seem more attractive than fewer, high quality engineers payed sufficient salaries to attract them.
I have been a close observer of code coming from India. I think the majority of the problems are because of vague, incomplete, and wrong requirements coming from the company that hired them. One company sent over someone. The guy spent a month talking to management, employees, probably the janitor and figured out what we actually wanted and the resulting code was decent.
This is part of the problem, and, in fact, part of the work of a software developer: given ambiguous and stupid requirements, you work with the customer to 1) make them clearer and 2) get rid of the unnecessary, complex requirements that do not bring any bussiness value. (My experience here shows though that it's not a standard thing in Indian culture to question the status quo).
There's a lot of implicit requirements that need to be taken into account when writing code: maintainability, security, performance, user experience, accessibility etc. It's better if everything is explicitly stated, but we don't live in a perfect world unfortunately. (My experience here shows that those implicit requirements are often not well executed, particularly when it comes to front-end code, due to a mix of: lacking experience, time pressure, different UX sensibilities).
Maybe it was just the firm I worked with, but they got the same requirements doc that the software was eventually written against using an American outsource firm.
The Indian firm wanted requirements so detailed that I had to tell them where to put the for loops and while loops. It was faster to just write the code myself than explain such easy details.
That is the problem with outsourcing in general: much of the work a development team do is figure out what the problem really is and how to solve it. The actual coding part is easy in comparison. But the business people didn't really see this, and....well...the results were predictable.
If a spec isn't vague, incomplete and wrong then you could just make a compiler that compiled the spec into working code and skip the programmer.
The job of a programmer is to map the vague notion of what the software should do, which is reflected in the spec, into a concrete, internally consistent set of instructions to the computer.
Not the OP but I can likely offer some insight as someone who has had to deal with teams in India: The biggest problem was the employee turnaround rate. Getting a developer, even an experienced one to become fully productive in your organization if you have several or complex products is a process that can take over a year but the turnaround rate was high enough that there we needed to use a very significant amount of resources dedicated to training and keeping communication and quality flowing smoothly because having people who weren't veteran enough to be able to handle themselves and figure out the business case behind the task and user story was a constant state.
I haven't dealt with IBM, but I have been in charge of outsourcing before. Early on we used Indians, but it became expensive so we moved on to the Philippines. Both had the issue you're describing. If you found someone good they would be gone in a few months for more money. I remember arguing with management above me because I wanted to pay a person 40k instead of 35k (I think those were the numbers, it's been awhile) because he was good, and communicated well (another issue). I was overruled and as soon as this person became proficient, and presumably found a better paying job he never showed up again.
Eventually I convinced management that even if we had to pay 2-3x for a competent developer stateside, it was worth the money because of the hidden costs of trying to outsource. The work we were doing required someone to be invested in learning the business and the problems we were trying to solve.
Of course. The point was that outsourcing was 'supposed to be cheap'. The reality is that for many situations it is not cheap, and is less expensive in the long run to pay a dev 100k or whatever the local market rate is instead.
The outsourced guy would eventually figure out that he is been paid way less for more or less same work. so they would move to better paying job. You would need to find a amount which is cheaper then US but way more then local market.
IBM has been arguably lost in the woods since the mid 90s, it got worse when they took over a consulting company who then convinced them to optimize for short term profits. Then it just gets worse from there.
I am just curious.. I havent purchased a single IBM roduct for maybe more than a decade (professionally and personally) -- the last major professional purchase was an AS/400 upgrade... 1998?
I have never bought an IBM-->lenovo laptop, although I have been provisioned some in various jobs...
What other main product(s) does IBM have that I would want?
they have great eng resources, scientists, etc... but I just dont see any of my money headed their way any time soon...
IBM is a massive consulting agency and they sell people's time and expertise to other companies. Customer projects, resource augmentation. Similar to Accenture and others.
The problem is that you will fall behind if you cannot transform your research into real products. Just like the smart planet idea, this idea is very brilliant and it was proposed around a decade ago, however the business around is a failure because of execution failure. Nowadays we are seeing other companies working on smart planet while IBM is changing to cognitive. What can we expect from cognitive?
Some personal thought, execution is key for business success now.
IBM SPSS is a product maybe not sure for you but IBM pushes a lot among Data Analytics Practitioners. They had their legacy in Market research companies. But democratisation of R and Python ate up a lot of market share from Sas and SPSS. Nevertheless still a lot of companies who used SPSS are still using it. It's an irony that IBM failed to capitalise the hype of Data science.
Those irons are only a small portion of IBM revenue now due to cloud. But they haven't put the correct resource on cloud and software. It was working in the past even though its software is very difficult to use. But now it's the other way around.
Liberty profile isn't exactly painful, but everything else Websphere is.
Regarding DB/2, I don't think that the installation process is the most interesting property of a database. The database is about as good as you can get, but there are certainly other options.
I tried installing WebSphere portal ten years ago for some reason and that killed my laptop. I'd say that that's probably the best possible outcome...
Oh, and I think TAM/TFIM/ISAM might be ok for companies over a certain size.
Not sure about their cloud offerings. Probably not promising.