Coding is basically learning how to breakdown problems into steps and be able to communicate those steps to a recipient (either human, AI or a computer).

Water douses fire.
All fire can do to water is make it change it's state to steam which eventually precipitates back down to douse fire.
Fire is so needy that it needs oxygen and fuel to keep going, it can't handle water.

Use Waterfox and really own your data.
https://www.waterfox.net/

Just do https://github.com/WaterfoxCo/... to get rid of that Firefox sign in nag.

If Lenovo did the same thing they may not be in the same rut was previously posted and commented on. https://slashdot.org/comments....

I run my teams with the "work where you think you're needed" approach. It does not mean we all do WFH, it means I leave it to the team to figure it out on their own. Some can choose to go to work because they're best at it some can choose to do remote everything because they are capable enough to get the work done.

---

This is augmented by 2-week sprint cycles and retrospectives to allow adjustments as needed. The productivity can vary and **value** velocity can be tracked (this isn't done yet just because we're still a small firm, but as we scale and add a role to just manage the analytics and reporting we can decide what needs to be done and have data to back it up from a management side rather than touchy feely stuff.

Regardless without those metrics, I have to at least go with the notion that we **trust** the workers we hire. If we can't then there's no point in keeping them hired. By trust I don't mean I expect them to always make perfect work, I just go with simple things like:

1. tell the truth or at least don't lie
2. don't produce harmful code (that is you don't intentionally write something harmful into the system)
3. you are ensuring someone can cover for you and you ensure you can cover for others.

For Amazon this is likely more difficult due to the scale and the likely integration of people using politics to prop themselves up rather than getting things done. What Elon did to Twitter basically eliminated a large number of dead weight. This is something that Amazon is likely doing, but get a lot of push back from the media when they do so. As someone said in a previous article... robots are treated better than people. Which should actually be the case.

The way I think about it is similar to... a proper medical doctor would strive hard to get you off medication rather than pushing medication as a crutch. When I did consulting, my prerogative was to make myself obsolete by getting the regular employees as self sufficient as possible.

My present executive role is to get my team members the tools to be leaders themselves WHILE I am actually producing VALUE for the company. Leadership is a quality not a role. The executive role primarily ensures that the buck stops with me in case there's a fall out.

I'd focus more of the business and professional end rather than catering to all groups. I'd also focus on reduce and reuse for the components. Also sell more for the repair facilities to leverage.

---details---
I'd simplify the product line, there should only be

T-series (for professional work)
X-series (for travelling work)
G-series (for gaming)

The X-series I would make as thin and portable as possible, but sacrifice customizability. i.e. no user replaceable parts. This would also be the cheapest in the line and the least repairable so it can be given out to operational employees and have it more or less disposable. I'd also set up a program with businesses to allow lease/recycling on this series because the shell could technically be reused and the internal board be swapped. The X would be the only one which can be folded back to become a tablet.

The T-series I would make as thin and portable as possible, but not sacrifice customizability. basically everything down to the processor is user replaceable. In order to save costs and engineering I would not bother with discrete graphics option. Since this would be more designed for professional work rather than gaming/graphics. The T's are also user replaceable screens so that 3rd party can swap it with a 4K display which we will do telemetry to check the general adoption. Also to save on cost and engineering and reuse the T's won't support tablet mode..

The X and T series would also be limited to 1080p FHD displays again to save on cost.

The G-series would be a different beast in that it's meant as a gaming grade device and the general bulk associated with it. It only comes in 17" 4K display screen with NVidia (or AMD exclusive whichever one gives us a better deal) option. Weighs like a tonne (well 6lbs). Also the G will not be foldable for engineering reasons.

I'd also add a G-dock which is a USB-C pluggable device that provides a graphics card slot that would allow offloading graphics workloads to it along with providing extra storage. This allows the X and T series to avail of discrete graphics.

Doing all of this the T and G series shells should be reusable for multiple generations. The shell structures could also be licensed at a relatively low cost so it can be 3D printed by 3rd parties with fancier materials since the company will only make stock matte black (glossy makes it easy to show dirt and grime and scratches)

Since there's **reuse** or minor iterations, costs would be lower and more beneficial for the environment than Apple's recycling approach. There's a reason why Recycle is last in Reduce-Reuse-Recycle. In fact this would be one of the selling point.

The minor iterations like updating to support new ports would simply swap the output of the shell.

This looks like a refresh of LISP/Scheme. Before they eventually added loops. They used tail recursion for iteration.

I personally like Trello which is what is being used in Stack Exchange (makers of Stack Overflow and its ilk) http://blog.stackoverflow.com/...

The article was the one that introduced me to the tool and I am impressed by it. Though it still needs some explanation of how to use it. I suggest you look at Kanban but don't mention it as a methodology etc... just explain how to group the work and be done with it.

Ya I still use it for my running my Linux servers, it does the job. Though it required an external add on to get it to run as a Windows Service. However, I used to not upgrade until they updated the Windows Service extension to work in any newer version.

If I had to prepare a curriculum I would probably be using JavaScript with JQuery and HTML for the intro course. The advantage of the language is the capability of quickly visualizing the application running with just a quick press of the reload button.

The use of JQuery allows us to bypass using CSS to make some visual changes to the HTML.

It will take a bit more preparation to create the template code that the students have to fill out initially though.

I would recommend doing both. There are significant advantages of moving some of the development/test tools out to the cloud. However, it should only go as far as development and perhaps first stage testing which is probably what your CTO has in mind.

There's no reason why each development project has to pay for the physical space taken up by *shared* development tooling such as Jenkins, Common Git Repository, JIRA/Redmine/Trac and some database and application server that is used for functional testing.

However, a proof of concept system must be present locally even if it is a limited capacity otherwise you'd be wasting a lot of bandwidth going back and forth.

It would also help to design your application architecture so that you can theoretically run everything on a laptop (and provide a powerful laptop to do it). For the developers.

If your'e an IBM shop, you may want to look at JazzHub to manage things for you.

I was thinking how about keeping it dark, while at the same have those UV light that they have in the bowling alleys to set the mood. Perhaps some constant vibration in tune with the music to prevent any stabilization of images.

Of course if you detect a flash you should take them out right away.

Normally the important part is things work on their target environment. So whatever approach you take does not matter as long as things will work.

If I am thrown into a new project, I start to do a few things if they are not available.

a) set up git and port the source code to my local git repository. This allows me to work in a version controlled environment that does not require me to show my intermediate work and experiments.
b) build it and make sure things do work.
c) create a test harness even if it is just to prove the welcome page works, I can add onto it as time goes by.
d) set up a coverage report to visually how the test cases flow through the app without stepping through a debugger (if you're lucky your language supports this, most of my projects are Java based so I have these tooling available)

Provide estimates. Don't say ASAP, always give a proper time, but not optimistic estimate. I tend to pad my estimates otherwise if something goes awry I would be accountable for them. I try to estimate based on a Jr. developer who is thrown into a project multiplied by two. However, if I do finish things sooner I let them know so the plans can change accordingly. If they want things sooner, still be firm and tell them that those are reasonable estimates given your analysis. They can choose to either accept them, try to allocate more resources (ideally) or kick you out (which is better than being burnt out)

Should your team grow, let other people know how you're doing things, there's no need to document every little thing, but be there to offer. Documenting everything you know will burn you out. As far as documenting things in detail go, I do make detailed install guides to get new developers up and running. However, that document ownership gets passed to the new developer for updates and refinements as things go.