russianator

FP (Functional Programming) has it's place. Sometimes a pure function is a beautiful thing to have.

It's also ok to mix OOP and FP.

If you do a lot of coding, it's just a better ride than "compressed" keyboards.

13" is a nice form factor, but I find the 14" X1 just has enough space to give a nicer typing experience.

Just my opinion, you should see if you can try one out, and see what you think.

Personally I actually prefer the IBM X1 Carbons, they have the nicest keyboard I've ever seen and a good keyboard is IMHO a must for a coder hacking keyboard.

You become a platform or product expert, which can effect your career in some ways.

I've seen this in situations where products from companies such as Salesforce are concerned.

I didn't want to become a Salesforce platform expert, I wanted to be able to pick the right tool for the job, regardless, and saw heavy investment into a single platform as a disadvantage both for the organisation as well as myself and our engineers.

The issue with nocode SaaS products is the misconception given to non technical people about what is replaceable.

Often a good business decision does not equal a good engineering decision and the management structures in place don't allow for this type of discussion to take place. This is where developers and engineers are beat out by "it's better for the business" as a decision.

Often executive managers who have moved away from technical work and are very far removed from deep (as opposed to wide) engineering knowledge, this can promote animosity between management and engineering.

Again this is purely a view/opinion from my own experience.

The organisation needs to understand: 1) What are the needs we are fulfilling 2) Are we building up engineering where we need it

When question 2 is disregarded when engineering built solutions are discarded this leads to the degredation of engineering "credit" in an organisation.

There should be open discussion about these things.

If his manager is enabling or ignoring this behaviour, I would wager there is some toxic culture in action here.

Having said that, you should have a manager that you can give and get feedack to and from. Be open to criticism but also note any behaviour you feel is unfair or unbalanced.

If it looks like noone cares to openly discuss this behaviour I would start looking for a new job.

It has built in gitops and a very simple deployment model. Works really well with custom domains and cost-wise it is great as it doesn't break the bank for my side projects.

It includes CDN capabilities with CloudFront-like honouring of cache headers, etc as well, so I haven't found anything lacking even though it isn't as feature packed as something like AWS Lambda.

For things like queues, databases and memory stores I used other managed services.

I go there from time to time when I get bored of Ubuntu :)

Rule number two, don't wait to have difficult conversations, do it as soon as something arises.

Rule three, delegate organisation tasks to your team.

I still struggle with time management personally, I'd be interested in others opinions on this as well.

You will have to balance delivery over care, or going fast over doing top quality work.

Solicit feedback from your team about how you can help them.

Also, work hard to prevent burnout.

The best way to gain trust is to show you are working for your team and not for your manager.

And don't ever listen when someone suggests one on one meetings with your team members could be a waste of time.

Supports Node.js, static and docker containers.

Very easy to use with custom domains.

But a more measured approach is to ensure it is flagged as a paywalled item.

I would also recommend learning tablature.

Often I see developers feeling trapped when they are unable to choose the best tools for the job.

Allow developers to be creative, period.

The best gun is the gun you don't have.

Less guns less gun violence, it's not rocket science!

Works flawlessly and the screen is very nice.

If your company is unwilling to change, change your company, find another job.

And priority one is your family!

Depending on your "workloads" you can start simple with just API's to support your frontends, and then expand your architecture to include services for other services. You would need to consider whether you need caches (redis) or databases (postgresql, mongodb, etc). All these can be containerised as well.

There are also frameworks such as next.js and nuxt.js which can ease the server side rendering side of things, depending on your choice of frontend view library (React/Vue).

In terms of orchestration and deployment, consider building your services with a Dockerfile.

I've had some success for personal projects using something like Rancher (1.x) for easier orchestration and scaling of containers. But at some stage you might want to learn how to use Kubernetes, since it seems to be the in thing now for container orchestration, scheduling, etc. Rancher allowed me to manage hosts and clusters on multiple cloud providers once I had the Rancher manager node setup.

So it can vary from case to case, depending on what your app actually does, you could still use koa+sequelize + passport for your API's. The above are just my own suggestions.

If you choose to go down the serverless road I would recommend checking out the Serverless framework, which can help you with deving as well as deploying to your cloud provider of choice.

Good luck!

Micro Node.js microservice library: https://www.npmjs.com/package/micro

React SSR framework: https://nextjs.org/

Vue SSR framework: https://nuxtjs.org/

Rancher for Docker things: https://rancher.com/docs/rancher/v1.6/en/

Serverless: https://serverless.com/

Feels like the team the writer was working on had some cultural issues around particular languages.

I have personally worked in companies where I've seen Java devs switch between Java and .Net languages without so much as a single whinge.

Overall a very biased piece of work IMHO.

They have a decent free plan and their Pro plan is pretty good value.