iamNumber4's comments

No, just call them directories, thinking of them as logical buckets to place things in them, which can be used to store data or direct you down further to find and location any information placed within the hierarchy structure.

Please note, if it is not broke don’t fix it. As well as new does not mean improved.

Also the file system found within computer operating systems were modeled after ways to categorize and store information that is both easy to use, and understand. Humans have been using systems like this for so long the inventors of that system are all but forgotten, as the concept can be seen through out history from how libraries have organized their collections of knowledge building, floor, isle, case, shelf, book, page, paragraph, sentence; all of which are conceptual examples of a directory. As well as other forms of systems in the same vain, country, state, city, district/neighborhood, street, block, house, room, file cabinet, drawer, folder, document.

Then as other suggestions in comments relational databases having database, table, row, column.

Each of those are also the concept of a directory.

Which can be defined as the ability to hold something, including more directories.

And a storage system can be described as a system of associated directories with a means of linking, nesting, indexing to provide means of navigation for location of things held within the system.

So, if there is a better way, humans have not yet grasped upon or discovered yet.

If you have ideas, go for it, but make sure your not reinventing the age old design with different nomenclature. You may also like looking into graph theory and object oriented design as areas of topics to learn about/discover.

It’s not that hard folks.

Anyone born in America (north, central, and south) are native Americans.

Some are of indigenous descent.

So when referring to a group of people we should just use terms of person and human. As there is no difference and none are better or worse than another.

If a person has an additional identity they describe themselves as a member of, then those terms should be used, Latino, Lakota, Hoosier, French, etc... when referring to groups of people who self identify with that group.

As that any given person could be of; or any combination of; any given cultural group. As that a person could be of Latino, Cherokee, French, Chinese decent, but live in Indiana. Referring to them as a Hoosier is true, as a Latino is true, as a Cherokee is true, ... is true.

Most importantly a human being is true.

Reduce reuse recycle comes to mind when I refactor code. Any code that is small does one useful thing that can be a candidate for a library. Catalog of useful library items should be well known within a code base so all code. When refactoring look out for things where the the current code may not be using existing library code and reinventing the wheel. Replace with code that does this with the library alternative. However if the current code has a fringe or divergent reason for not using the library function/method the library may need update to cover the fringe use case so there is no regression in the code your currently trying to refactor. Then also in the back of your mind be on the lookout for code that could be useful as a new library function, class or added to an existing class as a new method. When refactoring we want to reduce down as much as possible to useful reusable and code that can be well tested and well documented of its behavioral use cases.

The recycle is then to look at existing libraries to ensure they also follow the same rules as the current code which you are refactoring in the first place.

Then... you may still not be done. You need to then look at the pattern and structure of the code and look for code with bad smell (various levels of nested conditional statements, loops, etc...). Any thing you can do to remove layers of indented code, changing the structure if need be to be more linear top-down adding checks to short circuit, throw exceptions and then handle those exceptions. Basically anything you can do to improve the big-O of the code. This includes making sure all input parameters are validated and fail early if not. Then also output validation to ensure the return is sane. Then be on the lookout for security issues where the code may default to a true state, as you want to ensure if there is a problem you’re failing gracefully to a secure state so that there is not a hole or way to escalate security permissions, etc...

Then... look at unit tests, is there coverage of all of the code, is there well defined behavior documented in the unit tests, is there use cases you spotted not being covered by unit tests, is the code that rationally can’t be unit tested is that documented in the unit test code and then states this is end to end and logically can only be test through end to end testing, or other means (including documentation how those tests are run, if so).

When going through a process of refactoring, using reduce-reuse-recycle; you should develop a living document that is a check list of what to be on the look out for. Then when using the checklist, developers doing the refactoring process should start be taking notes of what the code does, intended use, and make observations based off what they are seeing. They can then later review those observations against code comments, api documentation, test frameworks, etc... to ensure that the code does what it says does against the previously existing documentation (if that even exists)

The other thing which is super important. Refactoring is not rewriting. You are not designing and implementing a solution or trying to change behavior. You are simply trying to make the code have a smaller cross section, and be more efficient be reducing it to common calls of library code. When you spot bad smell, questionable taste in design patterns you don’t fix it now, you document with code comments todo’s etc... and how to fix and open a new task to fix that section of code. Keep on going drilling down through the code layer to layer. Then you recycle again and start completely again when working those tasks just created. The goal is to create small easily worked rewrite tasks (at first) with sign posts to direct places in the code and what needs done. Then you will have a sense of scope needed to implement the refactor’s rewrite here, there, not using library here but should be, library is missing this feature move it from to there kinds of tasks.

Then risk management, and timeline management. Is it worth doing now, if so when do we do it and pencil it in?

Remember refactoring code is just math. Trying to reduce a complex equation down to its smallest form that can be easily understood.

Severance package. Try to negotiate for a few months of severance. Make sure the wording includes language for no longer employed by. So that if you decide to quit, or they let you go they will pay you a wage before any unemployment for a given term. But also includes it being open if you do start another job right away that they still owe you. Also try to get health insurance during the term as well.

Then at review time try to get more added time added to it. So that over time you can get more weeks of pay. This can be a bargaining chip if they can’t afford a giving a raise, that you would accept more time for the severance package instead of a raise. While it might also seem silly if a raise is offered but no increase in severance counter with a proposal with a smaller raise and severance.

Do this until you have 6 months to a year of severance. Start low with say 2-4 weeks but try for 12 weeks.

This will buy you protection in the future if work becomes hostile, or a super visor start pulling crap trying to make up bs on performance reviews to try to justify letting you go.

Make it expensive for you to leave the company and that they need to be honest, fair and ethical with you at all times, or you can play the fuck it card and sit at home and still get paid while you look for work. If they let you go same deal, but you then get any unemployment after the severance terms are up.

Laziness is the mother of innovation.

Hard working lazy people seek solutions to do the necessary work with smallest and most efficient way possible to achieve lowest level of effort possible.

Which all of above is the reason I like D Lang, as it is ABI compatible with C/C++. So all existing libraries and code written in C can just be used but also have the convenience of modern language design principles. Which unlike the other modern languages like Rust, Go, .Net, etc... it is not corporate owned and controlled. So being completely free and open source like C/C++, D is continuing build on top of what came before, but also bringing in modern languages safety for memory, types, as well as rtti (runtime type introspection), and being multi paradigm allowing procedural, OOP, and functional to all co-exist in the same code.

So that is why I think it is the best choice for my default language of choice.

D Lang is my default language

But it all depends on what. You should always use the right tool for the job. Don’t kill the fly with a bazooka when a fly swatter is all you need.

Funny title, especially considering its 9 to 5 Mac’s article.

The questions are; are you being accused of have poor communication skills by your boss?

Or are you just trying to improve your skill set?

If the just trying to improve look up effective communication, including topic like pathos, logos, and ethos, reading your audience, and non-verbal communication. You could also look at groups like toastmasters.

If you are being accused of poor communication by your employer or direct supervisor it’s time to look for a new job. As that this accusation is from certain management playbook techniques as was to deny employees promotions as it threatens the managers own career trajectory. As that you have done something intentional or not that makes them look bad or they need an excuse to justify a poor performance review.

Puff piece, no data, pure author opinions. If you like word salads then here is a good example.

Facts: the global temperatures average is still 2 degrees cooler than the 14th centuries. We are coming out of an ice age. Sure our pollution doesn’t help. I would like to point out, a single volcanic eruption produces more greenhouse gasses than humanity produces in a year. There are multiple massive eruptions every year in the ring of fire.

What does this mean?????

Plant a tree, several if you can. Will it do anything to solve global warming???? No but you’ll feel better.

Climate change is natural. Fertile areas become deserts, deserts become fertile. Ice melts, more green plants grow eventually sucking up the excess gasses. Eventually it becomes colder again.

It’s happened before us, it will happen after us.

Whoever states a number first looses the negotiation!

Or. Outlining the affect of the unwillingness of some employers to give far wages to existing employees when they bring in new employees at higher rates than existing employees.

As well as, reasons why people leave jobs for better pay and career growth.

If you hire new talent and compensate them better and don’t also raise compensation and or responsibilities for other existing employees your going to create feelings that lead to disengagement. Which gets us to people writing articles about how it’s better to grow employees vs, bringing in outside talent to the existing team.

If you have good culture, fair compensation and clear paths to career growth, then yes I agree growing in house skills will be better, with starting new employees at the bottom to not offend existing people you have invested in their career growth.

It sounds to me that the author has some experience with bad culture and was slighter by some new employees who may have gotten promoted or flat out hired above them without having more skills than they possess essentially killing their ability to move to higher rungs inside the organization.

I know this so wrong, but my friends and play a game “hipster or homeless”. Where we attempt from pure subjective observation try to determine if the person is down on their luck, or intentionally dressing the way they look.

There is a fine line, between the two.

Full disclosure I have been homeless, but just because I was in an unfortunate situation, I still tried to be a presentable human being. The situation I was in should also not take my dignity as the two were not related.

Lenovo flex 5 1570. It’s awesome. i7, upgraded to 16 gigs of ram. Running Ubuntu 18.04 everything works except fingerprint reader, but I don’t care about that.

Aluminum body, 15 inch form with a 10 keyless keyboard. So your hands are centered and don’t feel like your sitting left of the screen.

Was about 1000 bucks with the ram upgrade at the time. However now, it’s about 800 a year after I got mine.

This just in posinous mushrooms common to North America found in North America

Nothing to see here, peaked my interest since “who would pay for a compiler??” In the modern age of open source.

Post has a missleading title, and is just rambles about ruby and compilers.

True, the simple fact is you can’t out run your mouth. Exercise is good for other health reasons not for weight loss. In fact if your severely overweight jumping on a treadmill will damage your joints.

Intermittent fasting, and eating diets like unethical vegetarian (meat sometimes) are great for weight loss.

If your going to eat junk, binge, get it out of your system. Try to limit this to rare and appropriate moments. Birthday parties, event dinners.

Don’t feel bad you enjoy food, don’t take it away, just don’t eat junk regularly.

Do low impact cardio like swimming or biking, do low joint stress strength training (yoga or resistance weight training)

Relax, don’t stress, sleep more, eat less ( when your body tells you to eat only not because of the clock).

Relearn thirst vs. hungry. Your probably not hungry, just thirsty most times.

I think a mixture. Coining the term “Ban Scrum”. Which is a mixture of KANBAN and scrum sprints. Where the sprint is not over until an identified set of tasks/stories are completed. The truth about software development is, it takes as long as it takes. But you don’t have infinite time. So digest what needs done, carve up/reduce into the smallest workable step/task, group like things into sprints. Work those sprints until complete. This also allows for larger teams to work more sprints concurrently by dividing the dev teams up into smaller unit teams. Then having a single KANBAN board for management to watch progress. While also allowing for continuous development and rolling releases, eliminating the artificial deadline of the traditional scrum sprint and resulting crunch of code reviews a day or so before the end of sprint cycle.

Ritual meetings are similar, but there is never a end of sprint meeting/next sprint planning session. Rather a weekly sync up to talk about what’s working and what’s not, what can we do better. Then weekly backlog grooming to identify and group future sprints to get them ready to be started, when it is natural to start that work. Then of course daily standup to communicate roadblocks to managers so they are aware and can do their job to unblock the road, and also to promote general awareness to of other team members of what each other are doing.

This is the time to have a conversation about their role in the organization. They have opinions, sure, are those opinions argumentative by themselves probably not.

Most engineers want to know the why’s. If there in the dark on the big picture it can impact the overall results as they make wrong choices in design and architecture if they don’t know.

The conversation needs to be about their career path, and the aspirations. If they’re a good engineer, maybe they want to be more. Maybe their ideas are sound and they are being ignored which leads to frustration and more friction because they have insights of a problem you don’t see or are blind to.

I would suggest scheduling this first conversation, then daily or weekly 1:1 sync meetings. Keep them in the loop and feeling they are valued members of your team.

After you have reset your rapport with them. Listen to them, reinforce you have their back and part of the team. Delegate some responsibility through stewardship make them the owner of something. Let them succeed or fail.

If they still exhibit the same behavior, and can’t handle what you delegated to them, then it’s time for them to go.

Don’t loose a talent because you labeled them with a “communication issue”. The issue may be you are not listening or effectively communicating the direction or tone.

It also sounds from you post and described issue, is a result from your management style and possibly being a micro-manager. I could be wrong, but that is what I inferred.

Markdown, any existing text editor.

Low tech, shut the lid, place paper on it, use writing implement of your choice.