TL;DR;
Is this something I should worry about?
No, because you can't change or improve anything by getting worried. In fact, you might become desperate and make matters worse by doing something you could soon regret.
Give it time. Give yourself time to prove yourself, not only to yourself, but to everyone else in your team.
I'm not sure if I should start talking to my boss about my work because I'm new here and I don't want to sound like I'm bragging
The reason you have a team lead is because your boss has delegated that responsibility to your team lead. It's part of your team lead's job to communicate team progress to your boss.
That said, always be ready if your boss asks you directly. You could show your boss that the tasks given to you are being completed in a reasonable amount of time (based on their inherent complexity and effort estimates), with good quality, and that you've been doing this consistently.
I can totally relate to the "bragging" part and how it sucks. I think it depends on how you try to phrase things. To avoid that, just:
- keep your updates factual and objective (e.g. "I completed feature XYZ a moment ago and I'm now looking at ABC");
- be transparent when reporting progress (e.g. "Task ABC is taking a bit longer due to unexpected issues, but ______");
- avoid adjectives, superlatives, hyperbole, etc (e.g. "My amazing code compiled without any warnings after setting the most pedantic flags... b/c that's how I roll. 😏")
- note the priority, meaningfulness, and value of the tasks you completed, etc. (e.g. "Feature XYZ was marked as high-priority/importance")
For a bit more detail, please read on.
It Can Take Years to Earn Your Team's Respect
You mention that you joined barely 1 month ago. That's barely time to get "settled" into your role, learn the names of your team members, and start getting into the flow of only the most basic things, relative to other tasks within the team, who's already more familiar with the software being worked on and all of the associated details.
I'm assuming that, by getting "noticed", you mean acknowledged, recognized, respected, and/or treated as "reliable and competent" member of the team. In short, you need:
- Opportunity: You need to prove yourself to everyone. To do this, you need to solve meaningful and non-trivial problems competently, correctly, and with good quality. Doing something quickly, but wrong, won't help, so prioritize quality. If you're just doing "grunt-work", that may not give you much opportunity.
- Consistency: You need to show that you can do this repeatedly, rather than just a "one off" here and there.
- Trust: You need to earn your team's trust and respect. Having properly and factually informed opinions on the matters important to the team and software development in general (e.g. being able to properly justify software design decisions, just to name one, etc.) is very important here.
- Time: This is implied, but to show to your team that you can do all of the above, you need time. Nothing happens "overnight", nor should you expect it to. The length of your contract will play a role here.
It sounds like you're showing that you can do things to a degree that your team lead finds reasonably good, and that is good news, as long as your team lead has also met the above requirements. (An endorsement from someone already trusted and respected will have more weight behind it than that of a bad team lead.)
That said, you need to understand that none of these things can be generally achieved within just 1 month. Even if you pulled some 1 or 2 miracle solutions, you've still not been there long-enough to show long-term consistency, among other things.
Team Leads Must Continually Remind Upper Management About Their Team's Accomplishments
Something I think will be very important here is how good a job your team lead does when letting upper management know about the accomplishments of his/her team and their members.
In other words, even if team members are doing excellent work, the team's reputation with upper management depends on how well your team lead represents and "fights for" their teams.
I've seen good and bad team leads and the consequences that followed in both cases. I'm speaking from first-hand experience here. In one case, the bad team lead and the manager were so "out of sync", that the team lead asserted the tasks he was assigning were "very important", yet my manager, during my annual performance review no less, that the tasks I was working on were "not important". That's even leaving aside the fact that the process is inherently broken.
It was no coincidence that everyone in my team received poor performance reviews, compared to all the previous years when we had been with the good team lead.
Upper Management Does Not (Necessarily) Know (or Care) About Your Technical Details
In my experience, upper management doesn't care if you found a very clever solution to a problem by changing the data structure from a List that you needed to sort repeatedly over to a Priority Queue. In many cases, they probably won't even know what that means.
Take-away: Upper management (probably) cares about your source code as much as you (probably) care about Excel spreadsheets (read: not much). The truth of this statement is proportional to the size of the company in which you are.
At this level of abstraction, what "matters" is that things "work as intended", and that your team lead has done a good job in communicating your team's accomplishments, including yours as mentioned above.
