DEV Community: Tyler Wright

Remote Team Culture

Tyler Wright — Fri, 25 Dec 2020 19:28:12 +0000

I have always been a major proponent of team culture. Liking the people you work with (or at least tolerating them) can provide huge ROI's. Sometimes you come into an existing team culture and might either adapt or express your own culture. I intend to provide some solid team culture experience I've had and continue to pursue.

Take Inventory

What is the current team culture? What does the team want for a future culture. Is the team culture productive or counter-productive? Use team retrospectives to grow this side of your team. It is surprising that people that like each other tend to work better together.

Anyways, here is a list I use to build team culture.

Boardgames

There is nothing better than getting great minds alike to either solve fun problems together or working against each other. Boardgames are unique in the fact that you talk. Getting to know your team and building the culture of the team is a very important part of a successful team integration. Deeply integrated teams tend to operate at a higher capacity than dysfunctional and siloed teams.

How can you do boardgames at work when most of us are remote? Table Top Simulator is your answer. There are other options out there, but Table Top Simulator is king. Actually being able to manually play a game with zoom is kind of an amazing experience and a great team builder.

After Hours Team Outings

These are hit and miss and can easily end up in someone drinking too much and becoming a talk of the office. But consider your team culture. Would this embarrassment actually end up as a fun stab in the future, or will this affect the employees standing. This is all based on your culture.

Inclusiveness

If I was on a team and didn't feel included in the day to day discussions and decisions, I would not feel like a part of the team. This would directly affect my cultural impact on the team. Everyone should be included. Best, worst, no matter. Everyone is the same. Everyone has the same goal: success.

Team Conferences

This is a very expensive way to build culture. That said, it is also very effective. Bringing your team together in an intense learning situation can create a strong trust bond which is imperative for cohesion.

The How

I could keep going but I wont. I mainly wanted to get my opinions on how I view teams through culture. I would rather work on a team with good culture than a team where everyone is too serious. Team culture can be fun. If you don't have fun at work, find a way. Team culture can make work awesome.

So how do you go about setting up a team culture session in a remote world?

Boardgames - Steam/Tabletop Simulator + Zoom
Videogames - Any online server + Zoom
General - Zoom

Your thoughts

What do you think about team culture? Some of us thrive in isolation and other need that connection to people. I personally need that connection and conversations to keep me interested. What other ways could you grow team culture remotely?

Remote Work Reimagined?

Tyler Wright — Sun, 01 Nov 2020 03:56:38 +0000

This might be a dumb idea, so call me out on this if it is. With that out of the way, here we go:

I've been working on something that I'll be opening up to the community shortly. So, since I'm in the foundation phase, I've decided to start streaming my work through twitch (only one screen, my other is for "work"). Though no one watches my streams, it would be cool to have peer programming for pre-open source projects. Just a thought, but it might be fun. I could see this expanding into our workplaces. I could imagine it as an extension for Slack/Mattermost/etc, where you could turn it on or off.

So tell me, is this even worth attempting to implement or is this just after another pipedream project? ...Or worse...it already exists... Anyone interested in "#SocialProgramming (can I claim that term?)" with my on a typescript lib using twitch or just watching and giving opinions on why my code is "all wrong"...lol. If anyone is interested, I can schedule sessions as an experiment .

The Art of Development

Tyler Wright — Sun, 20 Sep 2020 23:26:46 +0000

If you are a developer, you are an artist. I don't care how STEM you think you are, you are an artist. You are creating a vision. Even if you are creating non-graphical interfaces, you are still creating something beautiful.

So now you're an artist! Congrats! What does it actually mean to be an Artistic Software Developer? I define it as a person who cares about technology and writing software. An Artistic Software Developer is someone who cares about the quality of code, the flexibility, the feel, to name a few. They have a passion for creating sustainable software. They care about code.

I know I am not a traditional artist. I've never been good at art. Sure I can edit a video and make it fancy, but I know that I am no traditional artist. No one is going to come up to me and ask for a painting. If someone would do that, they would get a terrible stick figure. But if someone were to ask me to write a simple calculator, I would develop it in a way that is: understandable, clean, protective, simple, and scalable. Just like an author creates beautiful sentences, we too can create beautiful code.

The day I started to see code as an art form was the day I became an Artistic Software Developer. The book, Clean Code, lays out a pretty good definition of good code. The book not old describes what good code looks like, it also explains why good code is good. It focuses on the fundamentals and the focus on readability and quality.

Be an artist. Care about code. Consider others and how they might view your code. To be a good Artistic Software Developer, you must have the ability to create software that is not only simple but also explains itself. Code can be art. Code is art. Become an artist. Care about your code!

The Grey

Tyler Wright — Sun, 20 Sep 2020 23:01:59 +0000

Have you thought about your future? Are you ready to get old? I know I'm not ready to get old! I do want to clarify what I mean by "get old". We all age, every second of every day. That is the human condition. I am not referring to that type of "old". I'm talking about aging out of your career. The day I age out of my career is very far away, but knowing that it will come is why I'm writing this.

Getting old...I'm a developer. I can't remember when I was not writing code. I love having the ability to write a sentence and watch the computer follow my orders. Am I getting old? Yes, I am but that does not mean I am aging out of my career. Instead, I am seeing my career in a new light. I don't have to be the best and pursue delusions of grandeur. I want to be a good developer and a good family member.

Have you ever put your career before your family? It sucks when it happens, but you justify it. I know I've justified having to work late and miss my son's Taekwondo lessons. Was it worth it? I don't think so. Family first. Family is my future!

I don't plan on getting "old", I plan on growing old. "Old", in my career mindset, means falling out of pace with the world. I'm not going to grow like that. How? By trying to be the best developer I can be all while keeping an eye on the future.

I will get old. I will get grey. I will get shorter (though 5'5 is pretty short). I won't stop learning though. I will never stop, no matter what my age is. Carpe Diem!!!

An Opinion: ORMS

Tyler Wright — Sat, 19 Sep 2020 23:16:05 +0000

Before I learned about the use of an ORM (Object-Relational Mapping), I handled all interactions with the database through either stored procedures or building a query and setting up parameters. It was not the most exciting part of development. When I was introduced to NHibernate, an ORM for .net based on Hibernate, an ORM for java, I jumped right in and started bringing it into my projects.

There are hundreds of different ORMs. The goal of most ORMs is to abstract interactions with the database, support multiple databases, and handle mapping. Some implementations also extend the base database functionality by adding caching, lazy loading, and bulk operations, to name a few. The most common denominator of these ORMs is that they generate SQL statements for you. Some do this through their own query language which could be string-based (HQL), or through methods that build the request internally.

In the past few years, I have completely moved away from using ORMs in my personal projects and when I have to work with ORMs, I am very cautious. I know SQL well enough to know what good SQL looks like. I’m also always having to work extra hard to ensure that the generated SQL performs well. ORMs can generate beautiful SQL, but it can also generate statements that are overly verbose and slow.

I’m not here to say that ORMs are evil and you must always stay away from them. I’m here to show the issues that using an ORM can bring to light. I want to start with the abstraction most ORMs provide. Abstraction is an amazing thing. ORMs use abstraction to provide a common API that can speak to different database flavors. The abstraction is what excited me at first. I thought being able to swap out the database with minimal changes to the code was amazing. I’ve used the ability to swap out a database, my use-case being that I wanted the ability to do unit testing against an in-memory database. It was pretty great, at least that was my opinion at the time.

Abstraction is not a bad thing. It can speed up development by dealing with most of the inner workings of database interactions. Where abstraction becomes a problem is that it is generating SQL for you. It is true that this opens the door for developers that are not comfortable with SQL, it forces developers to learn the ORM. Each ORM has a learning curve and each has its own API to interact with the database. This can cause developers to focus on the ORM, not the SQL it is generating. To be good at an ORM, I believe you not only need to understand the SQL it is producing, but you also must know how to use the API to get it to build the SQL you need it to produce. Most ORMs do allow you to write your own SQL, but that is typically not recommended, especially for the more opinionated ORM frameworks. There have been too many times that I have struggled to get ORMs to build SQL the way I need it. I typically find myself falling back to straight SQL for complex queries. ORMs are usually great at creating simple queries but when you need something more advanced, it can be tough to get what you need out of it. End of the day, my issue with the abstraction that ORMs provide is that they hide SQL. This can become a crutch for some people as they put off learning SQL and instead learn the ORM. If you need to switch to another language or system that uses a different ORM, you now need to learn the new ORM.

In my experience, to properly use most ORMs, you have to adapt your system to use it, which can become very invasive, requiring you to have to follow specific patterns to even use it. Some require you to use their own query language, others require you to build your objects with metadata. which is used to handle mappings. These are not bad things, but the more code you have to tailor to the ORM, the harder it is to replace it if you need to. Of course, you can abstract an ORM by isolating it and putting as much as you can behind interfaces but in my opinion, external dependencies such as a database should almost always be abstracted, especially if you want to bring in unit testing that does not actually hit the database.

I am a fan of almost anything that simplifies and speeds up development. Yes, ORMs do exactly that, but sometimes the way they do it can cause pain in the long run. I believe that anyone who uses an ORM should understand SQL well enough to understand the SQL that is generated. I also want to caution when using more advanced ORM features such as lazy-loading. These features can provide a lot of value but they can also cause unintended side-effects. I’ll never forget a bug that took too much time to track down. I was handling an object returned from NHibernate that had quite a few other table dependencies that were set up for lazy-loading. You could force the loading of the data at the time of the queries execution or you can let the ORM query the extra data when you need to use it. An example could be a User table. A user might have one or more roles. You would get a user object from the ORM and when you access that objects roles property, the ORM will execute an additional query to load that uses roles. This can be an awesome feature that can provide huge performance boosts. That said, it can also cause issues if your lazy-loading loads other lazy-loaded data. My bug was just that. Because of all of the lazy-loading, the state of my object and its properties were hard to debug. My issue ended up being that the state of the object didn’t always reflect the state of the database, especially as other processes were interacting with the same underlying data, changing the state of my dependencies as I accessed the lazy-loaded properties.

I’m taking my stab at creating an ORM for Typescript that is extremely lite and using its helpers is completely optional. I would say I’m about 60% done and I hope to finish it by October. I’m naming it nORM which stands for no ORM. when I’m ready, I’ll publish it to GitHub and create an NPM package.

https://www.devsplained.com