Forem: Victor Guzman

Coding without coding: What building with AI taught me

Victor Guzman — Sat, 19 Apr 2025 12:32:40 +0000

I’m a software engineer with nearly 15 years of experience. I’m currently director of engineering at a multinational company with over 150 engineers. Like many leaders in the tech industry, I’ve been watching AI move from novelty to necessity at an incredible pace.

More and more companies aren’t just encouraging AI adoption, they’re making it a mandate. While I support this shift, I also know (as a manager) that not every developer is excited about it. So I decided to experience it firsthand. Not through a tutorial or a demo, but by building a real, live product, from scratch, using nothing but AI.

The Idea: vinutils.com

I could’ve built a simple to-do app. But I wanted something useful. Something real. Something I could publish.

So I built vinutils.com, a free web tool for working with Vehicle Identification Numbers, things like validating, generating, or decoding VINs.

The entire project was built in just a few nights over the course of a week, using a framework I had never used before. I used Cursor, in thinking mode, with the Sonnet 3.5 model. For a few features and images, I used ChatGPT.

I didn’t write a single line of code manually. There were no code reviews. No product specs. No coordination with other teams. Just me, giving the AI a few prompts. The AI generated the code, fixed its own bugs, and made suggestions along the way. It felt fast, efficient, and, as someone who doesn’t code daily anymore, empowering.

The Good, the Bad, and the Unsettling

The most surprising thing? How well the AI could anticipate what I wanted. It often went beyond the prompt, and did it well. The speed of development, especially with an unfamiliar stack, was eye-opening. It made experimentation feel frictionless.

But of course, it wasn’t perfect. There were bugs. Cursor crashed. Files were deleted by accident. Sometimes the AI got stuck in a loop. Other times, it hallucinated or misunderstood even clear prompts.

And while I didn’t set out to learn the tech itself, I came away realizing: I hadn’t really learned it. Not the way I would’ve if I’d written everything by hand. The AI also made decisions, like which libraries to use, that I couldn’t fully vet. It worked, but I couldn’t always say it was the “right” way.

That’s where things get dangerous.

What This Means for…

Developers

For junior devs, the biggest risk is over-reliance. Using AI for even the simplest tasks robs them of the analytical thinking that defines good software engineers. Keeping up with tech is already hard, now it’s even harder when speed and output expectations rise.

But on the flip side, AI can be a fantastic silent mentor. It can explain code, walk through unfamiliar systems, and even do pair programming without needing to “bother” a teammate.

For senior engineers, the pressure is different. Increased expectations from leadership, more code to review (often blindly trusted by the dev who wrote it), and the challenge of maintaining quality in an AI-accelerated world. But there are upsides too, automating tedious tasks, validating ideas faster, and reclaiming time for higher-impact work.

Managers

The biggest challenge is cultural: how do you get developers to buy into AI, and use it well?

Used strategically, AI gives managers the chance to get closer to the code again, propose better solutions, and support teams more effectively. But even more important: it enables faster value delivery without growing the team proportionally. That means more experimentation, more iteration, and quicker feedback loop, all without organizational drag.

Companies

AI isn’t magic, it comes with real costs. If used poorly, it can generate waste or tech debt. But used well, it increases delivery speed, product velocity, and innovation capacity.

One overlooked impact: AI lowers the barrier to entrepreneurship. Anyone with an idea and a bit of time can now build and ship a product. That’s why we’re seeing a wave of solo founders and builders stepping out of corporate life to pursue their own paths.

Is This the Future?

Absolutely. But it’s not a full replacement. Not yet, and maybe not ever.

AI still needs human oversight, context, and judgment. It’s fast, yes. But we’re not at a point where we can trust it blindly. It’s not the end of the developer, it’s the next evolution of how we build.

If You’re Skeptical…

I’d tell you this: AI is just another tool. A powerful one, yes, but still a tool. You don’t have to be afraid of it. You just have to understand it and learn how to use it well.

Start small. Use it to explain code. Try it on a personal project. Let it surprise you. Once you experience the shift, it’s hard to ignore.

How ChatGPT wrote my first chrome extension

Victor Guzman — Sun, 19 Mar 2023 21:02:23 +0000

As a developer, I've always been curious about building browser extensions. However, I never knew where to start. That was until I started using ChatGPT.

With ChatGPT being the trending topic lately, I decided to run an experiment and test its capabilities. So, I decided to let ChatGPT build my very first chrome extension. And this is the blogpost on how it went.

About the extension

ChatGPT taught me how to build my very first browser extension, CSS Highlight. It allows users to highlight HTML elements with a specific class or ID using CSS.

About the process

The first step in building this extension was creating the manifest.json file, which provides information about the extension, such as its name and version, and specifies which files it will use. ChatGPT helped me create the file by providing a template and explaining each section in detail.

{
  "name": "CSS-Highlight",
  "version": "1.0.0",
  "manifest_version": 3,
  "description": "Highlight HTML elements with a specific class or ID",
  "icons": {
  },
  "action": {
    "default_popup": "popup/popup.html",
    "default_title": "CSS-Highlight"
  },
  "background": {
    "service_worker": "background/background.js"
  },
  "content_scripts": [
    {
      "matches": [
        "http://*/*",
        "https://*/*",
        "<all_urls>"
      ],
      "js": [
        "content/content.js"
      ]
    }
  ],
  "permissions": [
    "activeTab"
  ]
}

Once the manifest.json file was set up, ChatGPT helped me create the HTML, CSS, and JavaScript files for the extension. We started with the popup.html file, which contains the interface for the extension. ChatGPT guided me through the process of creating the layout and adding the necessary HTML elements.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>CSS-Highlight</title>
    <link rel="stylesheet" type="text/css" href="style.css">
    <script src="popup.js"></script>
</head>
<body>
    <h1>CSS-Highlight</h1>
    <form>
    <h3>Search for:</h3>
    <select id="searchType">
      <option value="both" selected>All</option>
      <option value="class">Class</option>
      <option value="id">ID</option>
    </select>
    <input type="text" id="identifierInput" placeholder="e.g. my-class">
        <input type="color" id="colorInput" value="#ffdc00"/>
        <div class="buttons-container">
            <button id="highlightButton" class="btn">Highlight</button>
            <button id="resetButton" class="btn">Reset</button>
        </div>
    </form>
</body>
</html>

document.addEventListener('DOMContentLoaded', function() {
  document.getElementById('highlightButton').addEventListener('click', function(event) {
    event.preventDefault();

    var searchType = document.getElementById('searchType').value;
    var identifier = document.getElementById('identifierInput').value;
    var color = document.getElementById('colorInput').value;

    if (identifier !== '') {
      chrome.runtime.sendMessage({
        name: 'highlight',
        searchType: searchType,
        identifier: identifier,
        color: color
      });
    }
  });

  document.getElementById('resetButton').addEventListener('click', function(event) {
    event.preventDefault();
    document.getElementById('searchType').value = 'both'
    document.getElementById('identifierInput').value = ''
    document.getElementById('colorInput').value = '#ffdc00'
    chrome.runtime.sendMessage({
      name: 'reset',
    });
  });
});

Next, we moved on to the content.js file, which is responsible for highlighting the HTML elements. ChatGPT helped me write the JavaScript code for the extension and explained how to use the Document Object Model (DOM) to manipulate the HTML elements on a web page.

let originalElements = [];

chrome.runtime.onMessage.addListener(function(message) {
  if(message.name === 'highlight') {
    highlight(message.searchType, message.identifier, message.color);
  }
  if(message.name === 'reset') {
    reset();
  }
});

function highlight(type, identifier, color) {
  if (type === 'class') {
    elements = document.getElementsByClassName(identifier);
  } else if (type === 'id') {
    var element = document.getElementById(identifier);
    elements = element ? [element] : [];
  } else {
    elements = document.querySelectorAll(`.${identifier},#${identifier}`);
  }

  for (var i = 0; i < elements.length; i++) {
    let element = elements[i];
    originalElements.push({object: element, color: element.style.backgroundColor});
    element.style.backgroundColor = color;
  }
}

function reset() {
  for (var i = 0; i < originalElements.length; i++) {
    let element = originalElements[i];
    if (element.object) {
      element.object.style.backgroundColor = element.color;
    }
  }
  originalElements = [];
}

With the help of ChatGPT, we were able to implement this background script using the WebExtensions API provided by the browser. The script listens for messages from the popup and content scripts, and relays those messages as needed. This allows for seamless communication between the different parts of the extension, making it work smoothly and efficiently for the user.

chrome.runtime.onMessage.addListener(function(message) {
  switch(message.name) {
    case 'highlight':
      chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
        chrome.tabs.sendMessage(tabs[0].id, message);
      });
      break;
    case 'reset':
      chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
        chrome.tabs.sendMessage(tabs[0].id, {name: 'reset'});
      });
      break;
  }
});

Final thoughts

Throughout the process, ChatGPT was patient, clear, and knowledgeable. As a language model trained on a vast amount of data, it was able to provide me with accurate and relevant information and guide me through the development process in a way that was easy to understand.

Building my first browser extension with ChatGPT was a fantastic experience. It was a great way to learn new skills, and I'm excited to see where this knowledge will take me in the future.

Real final thoughts

You've probably figured it out by now, but I also asked ChatGPT to generate this blogpost based on the entire conversation. So everything you just read was written by ChatGPT.

These are some of my conclusions (don't worry, these are written by me):

The first and most obvious are the limitations it has. Starting with the outdated and limited data. For example, the manifest.json originally created was in version 2 which is deprecated and I had to make manual changes to bring it up to version 3.
Generating the correct prompt to get the desired response is not an easy task. On many occasions I had to rethink it or even start over.
ChatGPT does not have all the answers. There was a specific error that took me a long time to figure out and after multiple attempts to get ChatGPT to give me the solution, I couldn't. To be fair, the error wasn't very well documented on google either.
The time that ChatGPT saves us is enormous. I was able to create the extension in one night, with no prior experience. And best of all, I now have a much better understanding of the basics of a Chrome extension thanks to ChatGPT's explanations. So I coded and learned faster than ever before.
I used GTP-3, and now I'm interested on seeing what GTP-4 would have done.

So, what's next? I'm planning to continue building the extension for fun and learning purposes, and obviously publish it on the store.

Bonus thoughts

I asked ChatGPT to write about its own limitations while doing this experiment:

ChatGPT is a language model and is limited by the quality and quantity of the data it was trained on.
ChatGPT does not have the ability to interact with the browser environment directly, so it was unable to test the extension code in the context of the browser.
The extension was built with a limited set of functionality, so it may not be suitable for more complex use cases.
The extension was not tested across a wide range of browsers and operating systems, so there may be compatibility issues with certain configurations.
ChatGPT is a language model and is not a substitute for an experienced developer who has a deep understanding of web development best practices and browser-specific quirks.

Developer Fears: Staying Relevant

Victor Guzman — Fri, 29 May 2020 23:24:47 +0000

About the series

This is part of a series of posts dedicated to talk about the biggest fears that we face as developers.

It took me a while to start this post and, being honest, I wasn’t even sure about writing it.

Of course, I could just write the same things you can find everywhere: keep studying, take online courses, read, and so on. But you already know that!

Instead, I’m going to share some things that I keep repeating myself when trying to stay up to date with tech. So, this is more like a how to avoid panicking rather than how to actually stay up to date.

1. Choose your needs

I can't think about anything that evolves as quick as the tech stack. Every week (or even every day) you will see a new language, framework, platform, pattern, tool... you just name it.

This makes it impossible to know all of them. And by know, I don't mean use it or read about it, I just mean know that it exists. So, my key is to choose what to learn based on the current needs, either mine or for the company.

If you're new on a company, or planning to stay more time on it, then focus on the company tech stack.

Make sure that you understand what type of company is: are they married with a defined stack or are they opened to innovation and trying new things?
What is the current tech stack, so you can start learning about it soon.
Are they planning new projects and considering new technologies? If so, then start reading about those. Even if they end up using a different technology, you will have learned something new.

But, if you're looking for a new job, then think about what you want and what the market is looking for:

Decide what would you like to work on. To do this, check what the companies are looking for, what the current top technologies are.
If you're feeling adventurous, look for things growing fast and that potentially will become popular in the short term. That would give you some advantage later when companies start moving into it.

2. Focus on the basics

Once you have learned to code in 2 or 3 different languages, you will notice that underneath they are all similar and that a lot of stuff that you previously learned helped you to learn faster.

That's why you should focus on more basic things. Rather than jumping right into a new language, first you need to learn how to create clean and quality code. Learn about different patterns and standards.

All those things would make you a better developer, and the sooner you do that in your career the better.

3. Learn from your job

People usually complains about having no time after work to study or learn new things. Well, we should learn to see the job as another source of knowledge.

If you pay close attention, you will find a lot of different ways to learn at job:

Look at other people's code. You can learn about different coding styles, small tips on specific technologies and a bunch of things that you probably didn't know.
Make sure to share knowledge. If you are, for example, learning about a new tool. Talk about it with your colleagues, it would help you remember what you learned and maybe they will learn something too.

4. It’s not all about coding

I've been conding for almost 10 years now, and this is something I learned on each company I've worked for: they value your coding skills, obviously. But something they value even more, is how much you get to know the company and business.

And that, is my final advice, make sure to be the go-to person when people need to know something. That will put you on a nice position and you will be able to help everybody not only by coding.

What about you? How do you keep relevant? Or what are your tips to avoid feeling overwhelmed?

Developer Fears: Breaking Production

Victor Guzman — Wed, 27 May 2020 21:26:00 +0000

About the series

This is part of a series of posts dedicated to talk about the biggest fears that we face as developers.

There’s always a first time

If you’re a new dev, you might be thinking: ”ha! It’s never happened to me”. Well, sorry to ruin your moment, but it’s just a matter of time.

On the other side, people who have been coding for a while probably already did it or know someone who did and have some great stories to tell!

But, don’t get me wrong, this is a good thing. Other than having funny stories to tell at the office, either if it was you or someone else, breaking production is one of the best moments that you have to learn and grow.

And talking about funny stories, let me tell you 3 of my favorites. But more importantly, let’s see what we all learned from them and how that helped us to improve.

The Jr hire that deployed on the first day 😱

It was the first day for a new junior dev. As part of the onboarding process, we let them follow the README with instructions on how to pull and set up the project locally.

We were focused on our stuff when suddenly received a notification that a production deploy had been made... by the new guy.

After a few seconds of panic, we determined that the deploy was triggered by a push to the canonical repo with no changes. Fortunately, nothing got broken and there were no casualties. What happened next?

Created a permissions policy: we realized that we kept no track of who has access to what, and that allowed the guy to push to canonical when he shouldn't. After that, all grants were revoked and a new process was set up to ask for access as needed.
Improved the README: we also noticed that the root of the problem was that the document wasn’t clear on how/where to run the command. So, we updated it and also start encouraging people to update it during the onboarding if they notice something wrong with it.

The SQL query without WHERE condition 😬

This is a common one, especially if you work with data.

There were a bunch of queries that need to be executed to update records on the database. The guy was selecting and running one query at the time and at some point he started screaming: "rollback, rollback!!".

He half selected the last query and didn't include the WHERE clause, updating ALL the records in the database.

What did we learn from it?

Backups are really important: thankfully, a backup was created before running the queries so it was easy to restore it. However, especially if it's a routine process, it's really easy to forget about backups and how important they are. Always make sure to create copies before starting any risky process.
Always test before running it live: it doesn't matter if it's a query, a command, or a script. It's important to have another environment to test before doing it in production.

💡 pro-tip: Start your queries by writing the WHERE clause, that way you make sure you don't forget about it.

The day that rollback didn’t fix it 💀

This one actually happened to me.

We were seeing an issue on the staging environment causing the page not to load correctly and leaving the application on a useless blank page.

We found the issue (or that's what we thought) and boom! It worked on staging. We immediately deployed to production, and it was supposed to be safe, but then we got the same error.

So we did what we always do, revert the last deploy. It makes sense, right? Well, it didn't work!!

It took us 1 hour to figure out the problem. Which means that users were unable to use the site for 1 hour and that's bad, really bad. And here's what we learned from it:

The backup plan won't always work: we learned this the hard way. The revert was our backup plan in case of fire, but it's not bulletproof. It's useful to have a backup plan for your backup plan. In our case, it was to call DevOps team.
It's not always code's fault: After all, we discovered that the issue wasn't in the code that we deployed. Instead, it was a configuration in the deployment process causing the dependencies not to update properly. So, just don't assume it's always the code, and try to see the whole picture instead.

Conclusions

Be careful!! Always double-check what you're doing and, if possible, ask someone else to look at it.
See something? Say something! The sooner you report the issue and everyone is aware of it, the sooner it can be solved and stop it from getting it worse.
Always learn as much as you can from it. I'm not saying that breaking production is a good thing nor encouraging you to do it. But if it happens, as long as we come out of it with a lesson learned or a process improved, it should be way less painful.

Have you ever broken production? Do you have any funny stories to share? Tell us!

Developer Fears: Legacy Code

Victor Guzman — Tue, 26 May 2020 01:50:52 +0000

About the series

This is part of a series of posts dedicated to talk about the biggest fears that we face as developers.

What is legacy code?

I’m sure that most of us have heard of legacy code, usually associated to something bad.

You probably have your own definition for it, just like everyone else. But let’s (try to) put a face on it.

I went through a lot of different pages looking for a standard to define what’s legacy code, and I came across with this definition and immediately felt identified with it:

Legacy Code is valuable code you’re afraid to change.

or written differently

Legacy Code is the code you need to change and you struggle to understand.

The important thing about this definition is to understand that every person has its own way to see legacy code and that it will depend on how familiar you are with the code and how do you feel about changing it.

Why code becomes legacy?

No longer maintained

There are many reasons to stop maintaining a piece of software:

It was successfully delivered
The business priorities changed
Limited budgets

Regardless of the reason, it’s imposible to keep updated a code that is no longer maintained, and it’s meant to become legacy.

Has no tests

This is a trick one.

It’s clear that anyone would be horrified of changing a piece of code that has no tests, specially if it’s a sensitive part of the software. And based on the initial definition, if you don’t feel comfortable, then it’s legacy code to you.

However, tests can give a false confidence if we assume that they are as good as they should be. And as I see it, that’s even worst than coding worried because there are no tests.

Developer is not around

The reality is, software is built through extensive periods of time, and usually it involves a lot of people working on the same code.

On one side, that’s something good! The more people involved with the code, the more people that can help to work on it.

However that’s not always the case. Sometimes, parts or even the whole software was in charge of a single person and, guess what? That person is no longer around, and it’s not documented, and has no tests... should I keep going?

What can we do?

It’s not always bad

Even though legacy code is considered to be a bad thing, that’s not always the case.

Most of the time, legacy code is still production code and it’s doing it’s job. The only problem is that no one wants to touch it.

What happens when the legacy code is no longer working as expected? That’s a whole different deal!

Your code will be legacy some day

The truth is, you probably won’t be on the same place you are forever. And even if you do, you won’t remember every single piece of code you have written.

Here are some things you can do to avoid nightmares to developers coming behind you:

Write tests: that would give people some confidence when changing it later.
Follow standards: understanding code written with the same standards, make the task way easier.
Document: yeah, probably you hate documenting too. But being honest, there’s no perfect code, and sometimes it’s just hard to read.

Reinvent the wheel or not?

Some people, specially on the business side, might think that re-writing a piece of software will cost the exact same effort and money than the first time. It’s not always the case.

You might want to balance both options, since each case is different from the other, redoing things sometimes is not that bad.

In summary: legacy code is there and will continue to be there, it’s relative to each person and we just can do small things to make it a little less painful.

How do you deal with legacy code?

Developer Fears: Estimation

Victor Guzman — Sun, 24 May 2020 22:04:06 +0000

About the series

This is the first part of a series of posts dedicated to talk about the biggest fears that we face as developers. Since that list can be huge, I'm not limiting it to a fixed number of parts and instead will let it grow as I get new ideas and suggestions.

Why are we (or think we are) so bad at it?

There seems to be a consensus out there that agrees on the fact that we're bad when it comes to estimations. I don't think I know a developer that has never underestimated/overestimated a task. Don't worry, you're not alone.

However, when you hear all those stories, there are some common factors that could help us understand why the estimations were so wrong. Let's see some of them.

Unknowns

Ideally, when you are going to estimate a new task, you will be provided with a detailed description of the requirements and scope. But let's face it, this is not an ideal world, and sometimes people are not clear about what they want but they still want to have an estimate.

When this happens, you need to understand that you can just give them a quick guess based on the few info provided and the previous experience you have. But that it won't be, by no means, an estimate and it's pretty sure that it's gonna change.

Confidence

No matter if it's under-confidence or overconfidence, this is an issue when trying to estimate things. Sometimes, developers tend to think that we can just sit and finish that task fast and clean and this can lead to underestimations. On the other hand, some developers don't trust their skills and usually overestimate tasks even if they're simple.

Pressure

This could be 2 things:

Internal: developers can feel the need to demonstrate that they're good at their work, and that includes estimations.
External: pressure can also come from people above us and, to be honest, that's most of the time.

Either if it's internal or external, we shouldn't let it to affect us. The truth is that it's ok not to know, and that we shouldn't give unreal estimates just to make us look good or to make people above happy.

Then, what can we do?

Don't worry, not all is lost. Here are some things that might help you to improve your estimates.

Choose an estimation technique

These are usually given by the company. In my case, we use the Fibonacci scale to estimate tickets.

Regardless the technique you use, the best thing you can do is estimate using ranges instead of explicit dates/times. This will give you some error margin to work with.

Break task

If a task is too big to estimate, it probably can be broken into smaller tasks. Defining what's big depends on each organization/team, in my case a task can't be higher than 8 on Fibonacci scale.

Spikes are your friends

I don't know what's your case but, to me, spikes are present on almost every development iteration.

And I have to say that they are super useful. Spikes bring clarity on how to approach a specific problem. Either if it's to create a small proof of concept or documenting a flow in the code, once you're done with it you will have a better understanding of what is involved on solving a problem.

What can we learn from all this?

We're not alone, this is something that every single developer has to face at some point in their career. But most importantly, it's not (always) your fault. Estimates involve a lot of stuff, including external factors that sometimes we can't control.

Have you ever been on a similar position? How do you deal with estimations? Tell us! We would love to hear about it and learn from it.

The First Post Experience

Victor Guzman — Thu, 21 May 2020 23:01:58 +0000

As developers, it's common to reach a time where we want to start writing. It doesn't matter if we are experienced or we just started our career, we always have something to say, something to share, something to teach.

Well, today was that moment for me. After some time thinking about it and doing some research, I decided to sit down and write my very first post. And what better way to do it, than by sharing what I learned from all this?

That's right, my very first post is about how I wrote my very first post (or how I call it: the post inception). And hopefully it's going to inspire other people, feeling insecure about it, to finally start writing.

What should I write about?

Choosing a topic for your post can be overwhelming, but it shouldn't be. You can start with something general, that will help you to feel comfortable and prepare you to increase the level of your next posts.

You can ask yourself some questions to help you identifying the topic of your post:

What do I feel comfortable enough to write about?
Is there a new project, tool or technology that could be useful for other people and that I could teach them?
Any recent news or articles that I would like to discuss about?

Answering those questions helped me a lot to decide my topic. After all the research and thinking, I realized that the whole process of writing your first post can be intimidating, so I decided to write about exactly that to help other people get over it.

At the end, no matter what topic you choose, the most important thing to remember is that it's your first post, it probably won't and doesn't have to be perfect.

Organize your ideas before writing

Before even typing the first word, it's important to estructure your ideas. Once you start preparing your post, you will notice that the amount of information available out there is overwhelming, and you can lose your flow really fast.

Start by defining the title of your post. This could be one of the most difficult things, but it will help you to have a more clear idea of what you want to write. Even though, the title you decided at the beginning may not end up being the final title, it will help you narrow your topic enough to focus on something specific.

Define the main ideas that you want to cover on the post and play around with them to identify the best order. You will know you are ready when you outline your post and can use it as a template that just need the gaps to be filled.

Write your post

At this point you already know what you're gonna talk about, how are you gonna structure the content and it is time to start filling the blanks. There's not much to say here, but here are some advices that I found really useful:

Write short paragraphs: big pieces of text can be hard to write and read, so make it easy for you and the readers.
Find the right format: a post can be structured in different ways depending on what you are writing. It could be a step-by-step guide, a few sections, etc.
Add images, video or graphics: if possible, include some images or interactive content. That creates engagement and helps you break the content.
Proofread and adjust: always proofread and edit your content as many times as you need, and make sure it has no typos or grammar errors.

Encourage feedback

Last but not least, make sure to let everybody know that suggestions and comments are more than welcome, at the end you are writing this for them. There is a lot more to learn now that you are getting into writing, and there is people out there with a lot of experience willing to help you.

Thanks for reading! I hope this really helps you.