Review on "The NEWSTACK - Platform Engineering - What You Need To Know Now"

 The NEWSTACK "Platform Engineering - What You Need To Know Now"

The NEWSTACK is a great resource for software developers/engineers to bring out relevant ways to stay informed, updated, and concurrent with job description outside of projects/homework using a media platform stance to remain strong in the business formatting. The structured economical recourse to transition our leadership delegates smoothly into familiar ground also opens up the close explanation of why technological businesses are going to be required within the future competition (if not already happening). 

The newsletter after signing up with The NewStack - was downloaded and easy to read. The documentation for what to expect using this light read was exactly what any student in the field is looking for in regards to atmosphere, expectations, and what to be equipped for upon the door opening moments of being titled with the degree and categorized toolsets, ready to start. 

A couple of things that I took from this (tremendous help in my future) - was how to envision your team and inter-departmental communications that will be in transitioning other teams, other facets of the project, and how to coordinate the API mangement necessities for each task. 

Using the Platform as a Product approach (following the cues of Software as a Platform, Infrastructure as a Platform, etc.) those who are using the Platform to develop are internal customers in the eyes of the ownership of the project. Logging progress to anticipate error or standstill operable time using multiple ways to measure this progress. 

    I agree with the user research to establish the customer personas (software devs) to produce a roadmap and backing system that is logged for tight feedback looping. But, the marketing aspect was puzzling to me. How do you get the service level objectives (SLO) for marketing to the internal customer without backlashing that previous time. Isn't this a no-no in regards to time management? I think this was under a sandbox operation for devs to encounter a free-space for what they would bring to the project and make it happen with the instruction of improvement and enforcing a strong interface system to rely on its foundation. I think the business venture is productive, but in doses of its ownership project. 

The Most Important Skills was documented and polled within these projects and I just want to highlight one:

Knowledge of System Integration (67%)

Ability to automate processes (61%)

Familiarity with CI/CD (54%)

Knowledge of performance monitoring (42%)

Ability to execute end-to-end performance testing (38%)

Addressing roadblocks to agility (38%)

Knowledge of Performance Monitoring caught my attention as my level of educational objectives at this time and I felt like if I knew what to focus during my studies on how to make a name for myself in the field, I would be a reliable source for that one specified objective. I did not know what it would be, thinking less than what I knew in the career, and glad to know now. The performance monitoring are free tools online that can be done with websites using analytical tools and staying within this sphere of tool making, improving, and reading its source through and through with expecting it in a specified place and branching from this point of contact. 

What are the steps of this? 

1. There has to be something to monitor. 

2. Find what tools work best in specified code, situations, presentation, deployment/publishing. 

3. Debugging.

4. Elude anti-patterns and creating new ones. 

5. Self-progress and making checkpoints based on structured code and mentorship breakthroughs. Taking note of logic, syntax, and inter-departmental (security, API, engineering, etc.) expectations. 

I wanted to suggest restructing the image of the platform as a living thing that gets bigger. With the small foundation that develops from it, time, and work - it is hard to let these things go and feel like its going to fall apart without those initial directories and infrastructural support systems. I would prefer using a directional path of prioritizing for open channels without breaking the project task load, time of win rates. The channels they build with secure the infrastructure (while avoiding another anit-pattern of using the code as infrastructure) using inter-departmental standards as checkpoints. This doesn't provide a shape for the project other than full figured and ready to dance. This has to be a project worth the time invested in by being effective with the direction first. I just didn't want to create something that everyone had to catch like a ripple in a pond to say that this is what they were going to do while it touched their part of the perimeter, to ripple back at the dev and their work to re-do and maintain that initial ripple. It just sounded too shifty for me to feel like it was secure enough to get work done. 

This was mentioned within the article itself, with professional advice provided here as its review can merely reiterate what these professionals are doing so well in. It is specified to learn that this group they did focus group research with, work well together, and how them doing their tasks with effective communication was key. This is going to have to remain flexible and update frequently with other tools (another key advice provided within the article). 

Conclusion

I am going to integrate the terms "SLACK" , "DEMO DAYS" , "LUNCH-AND-LEARNS" to the NEW-TRG group time/schedule to meet. I want to consistently create these IT atmospheres to become comfortable and custom to meet while engaging in projects without losing that humanity and humor of being with a group you work well with. 

As for the article, I will keep opening those newsletters and stayin informed as I pursue the Software Developer degree for its career experiences that await me. 

__Mischief